Stimmt es wirklich, dass UDP nicht einmal sicherstellt, dass ein einmal gesendetes Paket auch nur einmal ankommt?

Ist ja lustig.

Finde ich nicht.

Wie kommt das?

Das kommt, weil es so designed ist. Ansonsten wäre es ja TCP.

http://www.faqs.org/rfcs/rfc768.html schrieb:

This protocol provides a procedure for application programs to send
messages to other programs with a minimum of protocol mechanism. The
protocol is transaction oriented, and delivery and duplicate protection
are not guaranteed.

AFAIK kann ein IP-Paket z. B. mehrere Wege gleichzeitig durch das Netz nehmen und dementsprechend auch mehrfach ankommen.

Dazu müsste ein Host das Paket gleichzeitig über verschiedene Interfaces rausschicken. Wie und warum sollte das passieren?

Bashar schrieb:

Ich tippe mal, dass das passiert, wenn in Schicht 2 ein Frame ankommt, aber die Bestätigung verloren geht, so dass der Sender den Frame nochmal überträgt.

was meinst du damit? das ist ja kein duplizieren, sonder wieder senden.

gruesse,
mm

Bashar schrieb:

Ich tippe mal, dass das passiert, wenn in Schicht 2 ein Frame ankommt, aber die Bestätigung verloren geht, so dass der Sender den Frame nochmal überträgt.

was meinst du damit? das ist ja kein duplizieren, sonder wieder senden.

Was ist denn der Unterschied? Im Ergebnis wird der Frame zweimal empfangen, also ggf. auch als zwei IP-Pakete weitergeschickt.

http://www.google.com/search?q=cache:www.developerweb.net/forum/showthread.php%3Ft%3D2991 schrieb:

UDP packet take any path to reach the destination.So there is a possibality of duplicate packets to reach the destination.

Wenn ich genauer drüber nachdenke, fällt mir auch nur für TCP eine Begründung ein, warum das passieren könnte (z. B. ACK kommt nicht beim Router an). Aber ansonsten verstehe ich nicht genug davon, um meine Vermutung fundiert zu begründen.

Ich tippe mal, dass das passiert, wenn in Schicht 2 ein Frame ankommt, aber die Bestätigung verloren geht, so dass der Sender den Frame nochmal überträgt.

uebrigens, wenn layer 2 ankommt, dann auch 3 & 4...

mezzo mix schrieb:

Bashar schrieb:

Ich tippe mal, dass das passiert, wenn in Schicht 2 ein Frame ankommt, aber die Bestätigung verloren geht, so dass der Sender den Frame nochmal überträgt.

was meinst du damit? das ist ja kein duplizieren, sonder wieder senden.

Was ist denn der Unterschied? Im Ergebnis wird der Frame zweimal empfangen, also ggf. auch als zwei IP-Pakete weitergeschickt.

siehe mein vorheriges posting. das wird nicht passieren.

Bashar schrieb:

Ich tippe mal, dass das passiert, wenn in Schicht 2 ein Frame ankommt, aber die Bestätigung verloren geht, so dass der Sender den Frame nochmal überträgt.

uebrigens, wenn layer 2 ankommt, dann auch 3 & 4...

Ja, aber die bestätigen nicht (Schicht 4 jedenfalls nicht bei UDP).

Stimmt es wirklich, dass UDP nicht einmal sicherstellt, dass ein einmal gesendetes Paket auch nur einmal ankommt?

stimmt. udp macht keine annahmen über den transportkanal. siehste ja schon daran, dass im header prüfsummen sind, die bei den meisten, heute genutzten netzwerktechnologien überflüssig sind. wenn du mehrfache pakete wegfiltern willst, musste sowas wie sequenznummern einbauen.

Ethernet Flow Control sagt mir nichts. Ich sehe nur, dass du anscheinend die Schichten durcheinander bringst. Was interessiert es Ethernet, ob es TCP oder UDP überträgt?

ich verstehe dich nicht. ethernet ist so erstmal nicht verbindungsorientiert. punkt! dadurch entstehen keine duplikate, denn, und jetzt kommts, da wird nichts bestaetigt. das bleibt verbindungsorientierten protokollen vorbehalten.

mein vorheriges posting ist zwar salopp ausgedrückt, aber korrekt.

Bashar schrieb:

...aber so genau kenn ich mich da auch nicht aus.

ja, danke!

Was interessiert es Ethernet, ob es TCP oder UDP überträgt?

achso, frage nicht beantwortet: reichlig wenig. aber soll ein verlorengegangens paket erneut übertragen werden, kümmert sich tcp darum und nicht ethernet. wie kommst du eigentlich auf die idee? wer sagt überhaupt das udp über ethernet übertragen wird. steht nirgends in der frage. scheint eine annahme von dir zu sein.

ich hab mir deine theorie mal beim duschen überlegt. jeder ethernetport müßte demnach auch speicher besitzen, um das gesendete auch noch auf vorrat halten. gut, haben manche auch, jedoch nur für scheduler. bei 1 Gb/s sind das schon 0.125 MB für 1 ms.

aber ethernet könnte pro paket eine unmittelbare bestätigung verlangen, die karte müßte immer nur ein ausgangspaket speichern. (damit will ich nicht behaupten, daß ethernet das tut.)

Bashar schrieb:

Ethernet Flow Control sagt mir nichts. Ich sehe nur, dass du anscheinend die Schichten durcheinander bringst. Was interessiert es Ethernet, ob es TCP oder UDP überträgt?

ich verstehe dich nicht. ethernet ist so erstmal nicht verbindungsorientiert.

Na und, man kann auch auf Basis einzelner Pakete Bestätigungen verschicken.

achso, frage nicht beantwortet: reichlig wenig. aber soll ein verlorengegangens paket erneut übertragen werden, kümmert sich tcp darum und nicht ethernet. wie kommst du eigentlich auf die idee? wer sagt überhaupt das udp über ethernet übertragen wird. steht nirgends in der frage. scheint eine annahme von dir zu sein.

Ethernet hast du ins Spiel gebracht, ich rede von Schicht 2.

ich hab mir deine theorie mal beim duschen überlegt. jeder ethernetport müßte demnach auch speicher besitzen, um das gesendete auch noch auf vorrat halten. gut, haben manche auch, jedoch nur für scheduler. bei 1 Gb/s sind das schon 0.125 MB für 1 ms.

Soviel? Überzeugt, kann nicht sein :p

Ich weiß, was ich weiß, und ich hab kein Problem, zuzugeben, wenn ich was nicht weiß. Du meinst, das als Schwäche interpretieren zu müssen. Vielleicht willst du hier nur irgendwas beweisen. Vergiss es, dazu hast du zu oft vollkommen missverstanden wovon ich überhaupt rede. Falls du nur "gewinnen" willst, sag es einfach, dann können wir das hier beenden.

aber ethernet könnte pro paket eine unmittelbare bestätigung verlangen, die karte müßte immer nur ein ausgangspaket speichern.

die bestätigung ist, dass keine überschneidung stattgefunden hat. sonst macht der eth-chip wiederholungen. siehe hier: http://en.wikipedia.org/wiki/CSMA/CD
normalerweise hat so'n teil speicher für ein paar paketchen (selbst der olle 10Mbit/s ne2000 hatte welchen). ausserdem sagt ein ethernet-controller der software (treiber), wann er wieder für ein neues paket bereit ist (per interrupt, oder man pollt ein 'ready'-bit).

volkard schrieb:

(damit will ich nicht behaupten, daß ethernet das tut.)

WLAN macht sowas, weil das medium naturgemäss viel anfälliger gegen störungen ist.