UDP Broadcast - Pakete kommen nicht immer an

[sli92]

Hallo, ich hab ein komisches Problem:

Ich habe zwei Java-Programme geschrieben, das eine heißt netfinder und das andere module . Die netfinder Anwendung schickt einen Broadcast an z.B. vier Instanzen der Anwendung module, die alle vier auf einem anderen anderen Computer im gleichen Netzwerk laufen. Alle vier erhalten diesen Broadcast und antworten danach mit dem Text "Modul meldet sich", während die netfinder-Anwendung lauscht. Nun folgendes Problem, das ich auch mit wireshark reproduzieren lässt. Es passiert sehr häufig, das die "Antwortpakete" der Module-Instanzen auf dem anderen PC nicht ankommen. Ich habe folgendes Szenario mit wireshark auf Computer 1 (netfinder) und Computer 2 (4 module Instanzen) nachgespielt: netfinder auf CP1 schickt das Broadcast-Paket (wireshark zeigt das auf CP1 auch an). Das Paket kommt laut wireshark auf CP2 an. Alle vier module Anwendungen antworten auf dieses Paket per Broadcast, also gehen 4 Pakete von CP2 hinaus (wireshark zeigt das an). Und jetzt das Problem laut wireshark auf CP1 kommen aber nur 3 Pakete an, darum macht der netfinder auch nur drei Ausgaben statt vier. Ich bin einfach ratlos und habe jetzt auch nicht den Code gepostet, weil wie man sieht, dass das Paket verloren geht, aus irgendeinem Grund. Ich bitte um Hilfe!

 

[TheDarkRose]

Du weißt schon das bei UDP keine Garantie vorhanden ist, das Pakete ankommen? UDP Pakete gehen gerne mal verloren, darum wird es meist nur bei Audio/Video Anwendungen eingesetzt, denn da fallen die Verluste nicht auf.
Für den Rückkanal von module zu netfinder solltest du IMHO lieber TCP verwenden.

 

[Michael...]

Nun folgendes Problem, das ich auch mit wireshark reproduzieren lässt. Es passiert sehr häufig, das die "Antwortpakete" der Module-Instanzen auf dem anderen PC nicht ankommen.

Das ist die Eigenschaft von UDP. Es ist ein einfaches,

verbindungsloses

Protokoll. Hat den Vorteil, dass es ziemlich schnell ist, dafür allerdings Informationen verloren gehen können.
Wenn Du also sicherstellen willst, dass die Antwort der Clients garantiert beim Server ankommt müsstest Du das selbst implementieren oder dafür auf TCP wechseln.

 

[c_sidi90]

Wie schon gesagt garantiert UDP keine Datenübermittlung, allerdings habe ich damals einen UDP-Netzwerkchat geschrieben und einen Packagecounter eingebunden. Bis zum heutigen Tag sind 99 % aller Packete angekommen. Es ist also auch eine Frage der Programmierarbeit um gewisse Situationen abzufangen und zu behandeln. Stichwort "Sendungsüberprüfung".

P.S das Programm ist beinahe 11 Monate im Betrieb und jeden Tag werden im Schnitt mehrere Hundert Packete gesendet, die Erfolgszahl basiert also nicht auf Zufall.

Lg

 

[nillehammer]

UDP Pakete gehen gerne mal verloren,

Das ist kompletter Blödsinn. Die Wahrscheinlichket, dass ein Datagramm verloren geht, ist bei UDP und TCP gleich. Nur, dass man bei TCP eingebaute Mechanismen hat, um das zu bemerken und bei UDP eben nicht. Gerade in diesem Fall (nur lokales Netz) sollte eigentlich nichts verloren gehen.

In dem von Dir (sli92) beschriebenen Szenario kann es mit einem Broadcast nicht getan sein. Wenn Du auf einem Computer 4 Instanzen von module laufen hast, müssen diese ja auf unterschiedlichen Ports horchen. D.h. Dein Broadcast muss an die 4 verschiedenen Ports gehen, es müssten also 4 Broadcasts sein. Ich würde also vermuten, dass mit den Ports was nicht stimmt.

Ansonten noch der Rat, von Antworten per Broadcast auf Antworten ber Unicast zu wechseln. Ein Discovery (netfinder) per Broadcast ist ok. Aber bei der Antwort hat der Client (module) ja eigentlich die Information in der Absendeadresse des Broadcasts, um per Unicast zu antworten.

 

[Gast2]

UDP Pakete gehen gerne mal verloren, darum wird es meist nur bei Audio/Video Anwendungen eingesetzt, denn da fallen die Verluste nicht auf.

natürlich fällt das auf ... Pixelfehler / stehende Bilder / blecherner Ton / abgehackter Ton ... alles auf fehlende UDP-Pakete zurück zu führen ... UDP wird nur genommen wenn eine Echtzeitübertragung statt finden soll (z.B. Videochat) ... hast Du dafür TCP, dann sammelt sich die Zeit für die Neuanforderung der Pakete und irgendwann hast Du eine Zeitverschiebung von X Sekunden (oder gar Minuten) im Videochat ... unheimlich praktisch

Wie schon gesagt garantiert UDP keine Datenübermittlung, allerdings habe ich damals einen UDP-Netzwerkchat geschrieben und einen Packagecounter eingebunden. Bis zum heutigen Tag sind 99 % aller Packete angekommen. Es ist also auch eine Frage der Programmierarbeit um gewisse Situationen abzufangen und zu behandeln. Stichwort "Sendungsüberprüfung".

super - Du hast erfolgreich TCP in UDP Nachgebaut ... für Lehrzwecke in Ordnung - für Produktiveinsatz ???:L

Gerade in diesem Fall (nur lokales Netz) sollte eigentlich nichts verloren gehen.

doch - wenn es auf der Leitung zu Kollisionen auf der Übertragungsebene (kleiner OSI 4[?]) kommt ... das ist aber abhängig von der gesamten Menge der Daten im lokalen Netzwerk ... je mehr Daten um so mehr Pakete fallen weg

In dem von Dir (sli92) beschriebenen Szenario kann es mit einem Broadcast nicht getan sein. Wenn Du auf einem Computer 4 Instanzen von module laufen hast, müssen diese ja auf unterschiedlichen Ports horchen.

ich vermute mit 4 Instanzen meint er auch vier verschiedene Rechner

Ansonten noch der Rat, von Antworten per Broadcast auf Antworten ber Unicast zu wechseln. Ein Discovery (netfinder) per Broadcast ist ok. Aber bei der Antwort hat der Client (module) ja eigentlich die Information in der Absendeadresse des Broadcasts, um per Unicast zu antworten

jain ... die Geräte von Bosch (z.B. VIP-X1) reagieren genau so auf den Broadcast (255.255.255.255) ... die kann man auch super über Broadcast mit einer IP versehen ... aber ... die Antworten nur auf Unicast und dann findest Du die Mistdinger nicht mehr ... ich hatte erst im Anfang Sommer das Problem 90 Stück zu setzen ... erst als ich meinen Rechner in das Default-Netzwerk der Geräte geschoben habe, konnte ich die Geräte via Broadcast finden ... würden die Geräte ebenfalls via Broadcast antworten (255.255.255.255) wäre das nicht das Problem ... das Problem besteht aber erst seit neustem (keine Ahnung seit welcher Firmware) ... bevor Bosch VCS geschluckt hat, funktionierte es nämlich unabhängig der eigenen IP

hand, mogel

 

[nillehammer]

doch - wenn es auf der Leitung zu Kollisionen auf der Übertragungsebene (kleiner OSI 4[?]) kommt ... das ist aber abhängig von der gesamten Menge der Daten im lokalen Netzwerk ... je mehr Daten um so mehr Pakete fallen weg

Hier beschreibst Du einen in geswitchten Netzwerken sehr unwahrscheinlichen Fall. Das wäre natürlich eine theoretisch mögliche Ursache. Aber der Fehler liegt höchst wahrscheinlich woanders. Zumal immer dieselbe Instanz nicht antwortet.

ich vermute mit 4 Instanzen meint er auch vier verschiedene Rechner

Im Originalpost steht: "Computer 2 (4 module Instanzen) nachgespielt" Das hatte ich so interpretiert, dass es sich bei Computer 2 um einen Rechner handelt, auf dem 4 Instanzen von Module laufen. Kann mich aber natürlich auch irren...

jain ... die Geräte von Bosch (z.B. VIP-X1) reagieren genau so auf den Broadcast (255.255.255.255) ... die kann man auch super über Broadcast mit einer IP versehen ... aber ... die Antworten nur auf Unicast und dann findest Du die Mistdinger nicht mehr ... ich hatte erst im Anfang Sommer das Problem 90 Stück zu setzen ... erst als ich meinen Rechner in das Default-Netzwerk der Geräte geschoben habe, konnte ich die Geräte via Broadcast finden ... würden die Geräte ebenfalls via Broadcast antworten (255.255.255.255) wäre das nicht das Problem ... das Problem besteht aber erst seit neustem (keine Ahnung seit welcher Firmware) ... bevor Bosch VCS geschluckt hat, funktionierte es nämlich unabhängig der eigenen IP

Ich habe nicht geschrieben nur auf Unicasts antworten, sondern auf einen Broadcast per Unicast an den Absender antworten. Insofern verstehe ich nicht, was das mit dem Finden von "Mistdingern" zu tun haben soll. Die "Findeanfrage" soll ja per Broadcast gemacht werden. Nur die Anwort "Hallo hier bin ich" soll eben nur an den Absender der Anfrage gehen und nicht an alle.

255.255.255.255

So eine Broadcastadresse hab ich noch nie gesehen. Die Broadcastadress ist die höchste Adresse im jeweiligen Subnetz. Ein Subnetz mit der höchsten Adresse 255.255.255.255 wäre 0.0.0.0/0. So ein Netz wird sich kaum konfigurieren lassen (hab's aber ehrlich gesagt noch nie ausprobiert).

 

[TheDarkRose]

Broadcast ? Wikipedia

Es werden verschiedene Formen von IP-Broadcasts unterschieden:
Limited Broadcast
Als Ziel wird die IP-Adresse 255.255.255.255 angegeben. Dieses Ziel liegt immer im eigenen Netz und wird direkt in einen Ethernet-Broadcast umgesetzt. Ein limited broadcast wird von einem Router nicht weitergeleitet.
Directed Broadcast
Das Ziel sind die Teilnehmer eines bestimmten Netzes. Die Adresse wird durch die Kombination aus Zielnetz und dem Setzen aller Hostbits auf 1 angegeben. Folglich lautet die Adresse für einen directed broadcast in das Netz 192.168.0.0 mit der Netzmaske 255.255.255.0 (192.168.0.0/24): 192.168.0.255. Ein directed broadcast wird von einem Router weitergeleitet, falls Quell- und Zielnetz unterschiedlich sind, und wird erst im Zielnetz in einen Broadcast umgesetzt. Falls Quell- und Zielnetz identisch sind, entspricht dies einem limited broadcast.

 

[nillehammer]

Dank an TheDarkRose für die Klarstellung der Broadcasts (vor allem der Abschnitt zu 255.255.255.255). Hab ich wieder was dazu gelernt.

 

[Gast2]

Die "Findeanfrage" soll ja per Broadcast gemacht werden. Nur die Anwort "Hallo hier bin ich" soll eben nur an den Absender der Anfrage gehen und nicht an alle.

wie ich schon schrieb "jain"

per Default haben die Bosch Geräte 192.168.0.1 (die 192.168.0.0/24 ist aber im im gesamten Netzwerk nicht vorgesehen) - mein Rechner hat 192.168.45.212 ...wenn ich jetzt einen Ethernet-Broadcast absetze, antworten die Geräte an 192.168.45.212 ... da aber im Netzwerk keine Route zu 192.168.0.0/24 gesetzt ist, kommt die Antwort nie an ... antworten die Geräte mit Ethernet-Broadcast, dann erhalte ich eine Antwort ... somit habe dann die MAC-Adresse und kann mittels Broadcast wieder die IP setzen - Geräte sind im richtigen Netzwerk

wenn sicher gestellt ist das die IPs stimmen, dann natürlich Unicast

hand, mogel

 

[nillehammer]

Ok mogel, jetzt bin ich wieder bei Dir!

 

[c_sidi90]

super - Du hast erfolgreich TCP in UDP Nachgebaut ... für Lehrzwecke in Ordnung - für Produktiveinsatz

Es ist schneller als TCP bei kleineren Datenmengen und Broadcastfähig was für einen Netzwerkchat oder Chat allgemein von Vorteil sein kann ;P

 

[nillehammer]

Es ist schneller als TCP bei kleineren Datenmengen

Stimmt, der 3-Way Handshake und die Quittungen fallen weg.

und Broadcastfähig

Stimmt auch. Aber TCP ist natürlich auch Broadcastfähig.

 

[sli92]

Das ist die Eigenschaft von UDP. Es ist ein einfaches,

verbindungsloses

Protokoll. Hat den Vorteil, dass es ziemlich schnell ist, dafür allerdings Informationen verloren gehen können.
Wenn Du also sicherstellen willst, dass die Antwort der Clients garantiert beim Server ankommt müsstest Du das selbst implementieren oder dafür auf TCP wechseln.

Alles schön und gut, aber es sollte nicht jedes 3. Paket verloren gehen. Da muss es eine andere Erklärung geben. Ich habe den zweiten Broadcast (also den der 4 Programminstanzen) auf Unicasts geändert, leider tritt das Problem noch immer auf. Irgendwer schluckt die Pakete.

 

[Gast2]

Alles schön und gut, aber es sollte nicht jedes 3. Paket verloren gehen. Da muss es eine andere Erklärung geben. Ich habe den zweiten Broadcast (also den der 4 Programminstanzen) auf Unicasts geändert, leider tritt das Problem noch immer auf. Irgendwer schluckt die Pakete.

ja - Dein Netzwerk ... Du verwendest UDP, da werden eben schon mal Pakete bei Kollisionen geschluckt ... Du sendest Deinen Broadcast und alle Geräte antworten sicherlich sofort ... da werden auch sofort einige Kollisionen entstehen ... baue vor der Antwort eine zufällige Pause ein

 

[TheDarkRose]

Alles schön und gut, aber es sollte nicht jedes 3. Paket verloren gehen. Da muss es eine andere Erklärung geben. Ich habe den zweiten Broadcast (also den der 4 Programminstanzen) auf Unicasts geändert, leider tritt das Problem noch immer auf. Irgendwer schluckt die Pakete.

Warum schickst du den Unicast zurück nicht per TCP auf den Weg?