4. Wie jetzt, echt? Einmal gesendete UDP Pakete können mehrfach ankommen?

Wie jetzt, echt? Einmal gesendete UDP Pakete können mehrfach ankommen?

  • M

    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...

    0
  • M

    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.

    0
  • B

    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).

    0
  • M

    jetzt hab ich dich vielleicht verstanden. ich dachte du redest noch von udp.
    sowas kann nur mit tcp passieren, d'accord?

    0
  • B

    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.

    0
  • M

    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...

    0
  • B

    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?

    0
  • ?

    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.
    🙂

    0
  • M

    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!

    0
  • M

    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.

    0
  • M

    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.

    0
  • V

    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.)

    0
  • B

    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.

    0
  • ?

    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.
    🙂

    0
  • M

    volkard schrieb:

    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.)

    dann wuerde die datenrate drastisch sinken. da werden die signallaufzeiten ja schon relevant.

    Bashar schrieb:

    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.

    ich versuche dir diesen zahn zu ziehen, aber da scheinst du ja resistent zu sein:

    Bashar schrieb:

    Bei UDP und IP gibts aber kein ACK, in Schicht 2 aber schon, deshalb ist die Ursache wenn schon da zu suchen.

    neugeordnete udp-pakete, die durch erneutes senden auf layer 2 gesendet werden sind in der regel genauso gut wie verlorene. bei tcp gibt's race-conditions mit dessen flusskontrolle. denk mal drueber nach.

    0
  • M

    Bashar schrieb:

    Vergiss es, dazu hast du zu oft vollkommen missverstanden wovon ich überhaupt rede.

    du machst es einem auch nicht leicht, da du gefaehrliches halbwissen in die runde bringst.

    0
  • B

    mezzo mix schrieb:

    ich versuche dir diesen zahn zu ziehen

    Versuchs mal ohne mich dabei niederzumachen.

    Bashar schrieb:

    Bei UDP und IP gibts aber kein ACK, in Schicht 2 aber schon, deshalb ist die Ursache wenn schon da zu suchen.

    neugeordnete udp-pakete, die durch erneutes senden auf layer 2 gesendet werden sind in der regel genauso gut wie verlorene. bei tcp gibt's race-conditions mit dessen flusskontrolle. denk mal drueber nach.

    Denk mal hier drüber nach: http://en.wikipedia.org/wiki/Data_Link_Layer#List_of_Data_Link_Layer_services

    du machst es einem auch nicht leicht, da du gefaehrliches halbwissen in die runde bringst.

    Inwiefern gefährlich? Aus meinem Halbwissen mach ich keinen Hehl, aber dass es Retransmission auf Schicht 2 gibt und dass Duplikate durch verloren gegangene ACKs erzeugt werden können ist ein Fakt, es ist zumindest plausibel, dass dadurch IP-Pakete dupliziert werden können. Plausibler als der Vorschlag, das sei so aufgrund der verschiedenen Wege, die ein Paket nehmen kann, ist es allemal. Wenn du das widerlegen kannst, tu es, das würde mich sehr interessieren, vorzugsweise zusammen mit einer alternativen Erklärung für die Duplikation.

    0
  • ?

    Wie wäre es mit der Theorie, das einfach zwei Leitungen zu dicht liegen und das Signal (Paket) in die andere induziert wird?
    Wenn es zwei Leiungen sind, die an einem Router angeschlosen sind und das Signal stark genug ist, kann es weitergeleitet werden.

    Es steht ja nirgendswo, das die Duplikate durch die Art und Weise der Protokolle und oder Hardware an sich entstehen.
    Ich denke das ist so gemeint, dass das als "Unfall" passieren kann.

    So wie ein Blitz in Leitungen induzieren kann und lange 1111111111111111111111111 Zeichenfolgen entstehen können.

    0
  • ?

    Bashar schrieb:

    mezzo mix schrieb:

    ich versuche dir diesen zahn zu ziehen

    Versuchs mal ohne mich dabei niederzumachen.

    Bashar schrieb:

    Bei UDP und IP gibts aber kein ACK, in Schicht 2 aber schon, deshalb ist die Ursache wenn schon da zu suchen.

    neugeordnete udp-pakete, die durch erneutes senden auf layer 2 gesendet werden sind in der regel genauso gut wie verlorene. bei tcp gibt's race-conditions mit dessen flusskontrolle. denk mal drueber nach.

    Denk mal hier drüber nach: http://en.wikipedia.org/wiki/Data_Link_Layer#List_of_Data_Link_Layer_services

    du machst es einem auch nicht leicht, da du gefaehrliches halbwissen in die runde bringst.

    Inwiefern gefährlich? Aus meinem Halbwissen mach ich keinen Hehl, aber dass es Retransmission auf Schicht 2 gibt und dass Duplikate durch verloren gegangene ACKs erzeugt werden können ist ein Fakt, es ist zumindest plausibel, dass dadurch IP-Pakete dupliziert werden können. Plausibler als der Vorschlag, das sei so aufgrund der verschiedenen Wege, die ein Paket nehmen kann, ist es allemal. Wenn du das widerlegen kannst, tu es, das würde mich sehr interessieren, vorzugsweise zusammen mit einer alternativen Erklärung für die Duplikation.

    Wo soll es in UDP Ack's geben?

    0
  • ?

    fragenderRiese schrieb:

    Wo soll es in UDP Ack's geben?

    udp ackt nicht, aber der 'link layer' könnte acknowledgements einsetzen, um störungen usw. auszubügeln. theoretisch isses möglich, dass dadurch gesendete udp-pakete (und nicht nur die) dupliziert werden. bei WLAN z.b. wird jedes fehlerfrei empfangene packet durch einen 'ACK frame' quittiert. das wird durch den MAC layer so geregelt, die höheren schichten haben keinen einfluss darauf. zwar erkennt WLAN schon selbst doppelte (802.11) packete und lässt die garnicht erst durch, aber das ist'n anderes thema.
    🙂

    0
Anmelden zum Antworten