On Fri, Oct 17, 2003 at 11:13:49PM +0200, Thorsten Haude wrote: > Ist klar. Jetzt mal Klartext: Wir hatten eine kontroverse Diskussion > �ber dieses Thema, mein Gegen�ber meinte, da� SMTP beinahe immer mit > UDP benutzt wird, ich bin nach wie vor der Meinung, da� UDP allenfalls > in skurillen Ausnahmesituationen eingesetzt wird. Die fehlende > �bermittlungssicherheit bei UDP w�rde von SMTP ausgeglichen werden. > Sein Argument: Mails brauchen mal eine Minute, mal zwei Stunden, eben > weil UDP unzuverl�ssig ist.
Orn�. SMTP erkl�rt, wie sich Client und Server unterhalten m�ssen.
Also so Dinge wie:
C S
connect()
220 ESMTP
EHLO pc12
250 Hello pc12 [192.168.1.1]
MAIL FROM: <[EMAIL PROTECTED]>
250 <[EMAIL PROTECTED]> is syntactically correct
...
Um diese Informationen zu �bertragen, ist ein Transport-Protokoll
notwendig. Und das ist normalerweise TCP (k�nnte rein technisch gesehen
aber auch UDP sein).
Unsicherheiten von UDP sind nicht gr��er als die TCP. Ein totes Paket
ist ein totes Paket, egal ob's UDP oder TCP war. Diese Verluste werden
in normalerweise Gr��enordnungen von wenigen Sekunden ausgeglichen.
> auch eine Quelle, mit der sich die Antwort belegen l��t. Gibt es eine
> technische oder standardm��ige Bindung von SMTP an TCP oder UDP? Gibt
> es ein Ausschlu�kriterium, warum SMTP nur sinnvoll mit dem einen oder
> anderen zusammenarbeiten kann?
Nein.
Belegen? Wenigstens finde ich mit google keine Implementation von SMTP
�ber UDP.
> Bonusfrage: Warum braucht eine Mail mal eine Minute, mal eine Stunde?
Die Mails brauchen (mal abgesehen von Megamails, die einfach f�r den
Transport von einem Server zum n�chsten so lange brauchen, weil die
Leitung zu d�nn ist) nicht f�r den Transport so lange, sie liegen halt
mitunter auf den Servern rum. Mail ist "Store and Forward". Also -
jeder bringt sie zum n�chsten Mailserver, von dem er denkt, er ist
besser geeignet. (Wenn Du Dir die Received-Header der Mail ansiehst,
dann erkennst Du das.) Und aus verschiedenen Gr�nden kann es sein, da�
dann nicht sofort weitergeleitet wird. (Last, Zielhost down,
Viren/Spam-Scanner, ...)
> >Eher wichtig scheint mir, da� wahrscheinlich kein bekannter SMTP-Server
> >SMTP �ber UDP unterst�tzen wird. Es w�re zu anstrengend f�r den, der's
> >implementieren mu�.
> Ok, aber warum?
Was "warum"? Warum's zu anstrengend ist, oder warum's keiner macht?
Bei UDP schickst Du Pakete durch die Welt. Der Gegen�ber bekommt diese.
UDP garantiert Dir lediglich, da� die Pakete unverst�mmelt ankommen.
Aber nichts �ber die Reihenfolge. Schlimmer - es garaniert ja nicht
mal, *da�* sie ankommen.
Damit Daten auszutauschen, die gr��er als ein Paket sind, ist sehr
m�hsam, denn die Anwendung m��te die Reihenfolge und Vollst�ndigkeit
dieser Pakete selbst managen. Wer will das?
(DNS hat's da einfacher: Die Frage pa�t in ein Paket und die Antwort
normalerweise auch. Ich mu� dann nur noch rausfinden, ob ich fr�her
oder sp�ter f�r alle Fragen auch Antworten bekommen habe (bzw. die
Antworten, die ich erhalte auch zuordnen.) F�r diesen Zweck ist UDP
sehr gut geeignet, weil's auch keinen "Verbindungsaufbau" gibt (der bei
TCP ein 3maliges Hin&Her ist, was bei langen Laufzeiten st�rend sein
kann und Overkill ist, wenn ich mal eben nur eine Frage habe)).
Will ich UDP nutzen f�r den Mailtransport, w�rde es also so enden, da�
ich alles das, was TCP bietet, nochmal nachbaue. TCP stellt mir eine
"virtuelle" Verbindung dar. Ich connect()e mich und schicken dann meine
Daten dort einfach rein und das war's. Und gehe davon aus, da� der
TCP-Stack auf beiden Seiten die Vollst�ndigkeit (Reihenfolge und
Vollz�hligkeit) selbst kl�rt, mich das also nicht mehr angeht..)
Best regards from Dresden
Viele Gruesse aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ------------------ internet & unix support -
<a href="http://debian.schlittermann.de/";> Debian DVD/CD </a>
Heiko Schlittermann HS12-RIPE -------------------------------
pgp: A1 7D F6 7B 69 73 48 35 E1 DE 21 A7 A8 9A 77 92 -------
gpg: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B -----
pgp00000.pgp
Description: PGP signature
