Bei verkabelten Netzwerk werden UDP Nachrichten vom IP Stack normalerweise nur einmal gesendet und dann hofft man, das die Nachricht irgendwie beim Empfänger ankommt. Der Empfänger verwirst die Nachricht, wenn die Prüfsumme nicht stimmt. Soweit ist das richtig, oder? Nun habe ich mal im WLAN ausprobiert, wie viele UDP Pakete nicht ankommen (Laptop als Sender und ein ESP8266 als Empfänger). Zu guten Zeiten habe ich weniger als 1% fehlende Pakete beim Empfänger. Aber so zuverlässig ist die 2,4Ghz Übertragung doch gar nicht - denke ich jedenfalls. Daher vermute ich, daß die WLAN Technologie eine zusätzliche Sicherungsschicht enthält. Kann das sein?
Sinn des Schichtenmodells ist es, dass die übergeordnete Schicht nicht von der Implementation der darunterliegenden abhängig ist. UDP über WLAN ist also das gleiche wie über Ethernet Stefan U. schrieb: > Aber so zuverlässig ist die 2,4Ghz Übertragung doch gar nicht - denke > ich jedenfalls. Wenn in der unterliegenden Schicht - also den Frames - irgendwas kaputt geht, kann es gut sein, dass es von dieser Schicht auch korrigiert wird. Die Antwort ist also: Nein UDP hat keine anderen Features wie über Ethernet, kann aber gut sein, dass die Hardware Schicht bei WLAN retransmission implementiert wenn etwas unterwegs kaputt geht.
Felix U. schrieb: > kann aber gut sein, dass die Hardware Schicht bei WLAN > retransmission implementiert wenn etwas unterwegs kaputt geht. Das muss sogar sein! Überleg mal was passiert wenn der PC diese reTX auslöst. Es muss ja bekannt sein wo der Fehler auftrat.
Stefan U. schrieb: [...UDP...] > Soweit ist das richtig, oder? Jepp. > Nun habe ich mal im WLAN ausprobiert, wie viele UDP Pakete nicht > ankommen (Laptop als Sender und ein ESP8266 als Empfänger). Zu guten > Zeiten habe ich weniger als 1% fehlende Pakete beim Empfänger. > > Aber so zuverlässig ist die 2,4Ghz Übertragung doch gar nicht - denke > ich jedenfalls. Das kommt schlicht auf's Umfeld an. Logisch: Du besitzt das Band nicht exklusiv. Wenn weiter nix los ist, dann kann man lt. WLAN-Standards natürlich sogar 100% korrekt übertragene Pakete erreichen, denn das ist ja immer das Ziel. Es kann doch nicht so schwer sein, das Konzept eine "shared medium" zu begreifen? --- -- Beleidigung gelöscht. -rufus
> kann aber gut sein
Das ist meine Frage. Gibt es unter Ethernet im WLAN eine zusätzliche
Sicherung oder nicht?
Felix U. schrieb: > Die Antwort ist also: Nein UDP hat keine anderen Features wie über > Ethernet, kann aber gut sein, dass die Hardware Schicht bei WLAN > retransmission implementiert wenn etwas unterwegs kaputt geht. Wer soll bitte beim UDP eine Retransmission anfordern, wenn ein Paket beispielsweise als Broadcast raus geht. Das würde ein schönes Geschrei geben. Bei UDP ist per Protokolldefinition nicht sicher gestellt, dass ein Paket überall ankommt.
Stefan U. schrieb: > Das ist meine Frage. Gibt es unter Ethernet im WLAN eine zusätzliche > Sicherung oder nicht? Auf Layer 2 (MAC) gibts eine re-transmission bei Fehlschlägen auf diesem Layer (ACK). Wie diese genau aussieht, hängt von vielen Faktoren ab. Mit UDP hat das ganze nichts zu tun.
Beitrag #5151428 wurde von einem Moderator gelöscht.
my2ct schrieb: > Wer soll bitte beim UDP eine Retransmission anfordern, wenn ein Paket > beispielsweise als Broadcast raus geht. Broadcast ist auch bei WLAN eine andere Sache. Dann gibt es auch dort kein re-transmission auf Layer 2.
Stefan U. schrieb: > Das ist meine Frage. Gibt es unter Ethernet im WLAN eine zusätzliche > Sicherung oder nicht? Ja, es gibt eine zusätzliche Sicherung, nein, es gibt keine Rekonstruktion. Sprich: die zusätzliche Sicherung sorgt nur dafür, das die Wahrscheinlichkeit zur Erkennung eines Fehlers steigt, aber nicht dafür, dass der Fehler irgendwie ausgebügelt wird.
c-hater schrieb: > Sprich: die zusätzliche Sicherung sorgt nur dafür, das die > Wahrscheinlichkeit zur Erkennung eines Fehlers steigt, aber nicht dafür, > dass der Fehler irgendwie ausgebügelt wird. Das ist falsch. Der IEEE 802.11 MAC Layer führt Re-transmissions durch, wenn der Fehler auf diesem Layer geschieht.
MaWin schrieb: > Das ist falsch. > Der IEEE 802.11 MAC Layer führt Re-transmissions durch, wenn der Fehler > auf diesem Layer geschieht. Wie soll das funktionieren? Das Problem der Broadcasts wurde ja bereits erwähnt, Aber auch bei Unicast: auf dem MAC-Layer gibt es kein "ACK", denn das würde in "guten" Zeiten massiv Bandbreite verschwenden. Ohne so ein ACK kann kann es aber keine Retransmission geben.
MaWin schrieb: > c-hater schrieb: >> auf dem MAC-Layer gibt es kein "ACK" > > Doch. Tja, nun fehlt eigentlich nur noch eins: der Beleg für deine Meinung, gerne auch in Form eines simplen Links, man will ja niemanden überfordern...
c-hater schrieb: > Tja, nun fehlt eigentlich nur noch eins: der Beleg für deine Meinung, > gerne auch in Form eines simplen Links, man will ja niemanden > überfordern... https://www.google.de/search?q=IEEE+802.11+ACK
Danke für eure Antworten. Die richtigen Stichwörter zum weiterlesen habt ich jetzt auch.
Stefan U. schrieb: > Aber so zuverlässig ist die 2,4Ghz Übertragung doch gar nicht - denke > ich jedenfalls. Daher vermute ich, daß die WLAN Technologie eine > zusätzliche Sicherungsschicht enthält. Kann das sein? Ja, hat sie. Aber Vorsicht: Ich habe auch viele doppelte Pakete vom WLAN gesehen. Kommt Deine Anwendung damit klar?
> Ich habe auch viele doppelte Pakete vom WLAN gesehen. > Kommt Deine Anwendung damit klar? Damit muss man bei natürlich rechnen, wenn man auf TCP verzichtet. Auch auf die Reihenfolge der Pakete ist kein Verlass.
c-hater schrieb: >> Der IEEE 802.11 MAC Layer führt Re-transmissions durch, wenn der Fehler >> auf diesem Layer geschieht. > > Wie soll das funktionieren? WLAN transportiert zwar Ethernet-Frames, ist selbst aber kein Ethernet sondern WLAN 802.11<sonstwas>. Verkapselt also Ethernet Frames in WLAN Frames. Weshalb auf dem Layer unterhalb Ethernet sehr wohl Retransmissions erfolgen können. Davon kriegt dann weder Ethernet noch UDP etwas mit. Man muss in solchen Konfigurationen nur aufpassen, dass evtl. vorhandene Retransmissions mehrerer Layer sich nicht durch unabgestimmte und ungünstige Zeitparameter aufschaukeln. Unten kurz, oben lang ist ok. Andersrum kann sich der Kanal permanent mit Retries zustopfen, ohne dass ein einziges Nutzbyte durchkommt - das hatte ich mal bei einem Anbieter, der ein eigenes von sowas wie RS485 stammendes Protokoll sinnloserweise auf TCP statt UDP draufsetzte, was wiederum über ein falsch betriebenes Modacom lief (frühes Mobilfunk-Messaging).
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.