Wie jetzt, echt? Einmal gesendete UDP Pakete können mehrfach ankommen?
-
AFAIK kann ein IP-Paket z. B. mehrere Wege gleichzeitig durch das Netz nehmen und dementsprechend auch mehrfach ankommen. TCP erkennt das und verwirft Duplikate, UDP tut das nicht.
-
Hab ich mir doch fast gedacht.
Thx, *pThread erledigt.
-
Registrierter Troll schrieb:
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?
-
auf layer 2 kann ein paket prinzipbedingt schon mal dupliziert werden. es kann aber nur zweimal ankommen, wenn du eine switching loop hast. also verkonfiguriert.
auf layer 3 kommt sowas nicht aus versehen vor.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
-
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.
-
Ich habe die genauen Hintergründe nicht präsent, ob, wie und unter welchen Bedingungen das passieren kann - deshalb auch "AFAIK".
Hier steht auch sowas, allerdings ebenfalls ohne genauere Begründung.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.
-
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...
-
Bashar schrieb:
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.
-
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.
uebrigens, wenn layer 2 ankommt, dann auch 3 & 4...
Ja, aber die bestätigen nicht (Schicht 4 jedenfalls nicht bei UDP).
-
jetzt hab ich dich vielleicht verstanden. ich dachte du redest noch von udp.
sowas kann nur mit tcp passieren, d'accord?
-
OK nochmal Klartext, vielleicht ist das ja verloren gegangen. Die Frage war, wann wird ein UDP-Segment dupliziert? Typischerweise entstehen Duplikate, wenn ein ACK verloren geht. Bei UDP und IP gibts aber kein ACK, in Schicht 2 aber schon, deshalb ist die Ursache wenn schon da zu suchen. Der eine Knoten sendet also ein Frame zum nächsten Knoten, der bestätigt, das kommt aber aus irgendwelchen Gründen nicht an. Knoten 1 schickt den Frame also nochmal, und wenn der ankommt, haben wir eine Duplikation, die sich in den höheren Schichten fortsetzt.
Das mit dem Switching-Loop ist mir nicht klar, aber so genau kenn ich mich da auch nicht aus.
-
du redest von ethernet flow control?! da wird nichts wieder gesendet, ausser es handelt sich um tcp traffic. um das erneute senden kuemmert sich in dem fall layer 4, und nicht 2. ist es udp, ist der traffic futsch...
-
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?
-
Realisator schrieb:
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.
-
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. 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!
-
Bashar schrieb:
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.
-
mezzo mix schrieb:
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.)
-
mezzo mix schrieb:
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.
-
volkard schrieb:
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.