UDP Daten kommen nicht an

[flash2910]

Hallo Leute,

hab nen kurioses Problem:
Ich hab ein Programm programmiert, das mehrere UDP-Pakete hintereinander verschicken soll.
Das Problem: die Daten kommen nicht alle an. Wenn ich jetzt jedoch mit Thread.Sleep eine Pause zwischen die Sendungen lege, funktioniert es. Ist aber keine Option für mich, da die Clients in Echtzeit reagieren sollen, was ja damit nicht gewährleistet ist. Kennt jemand das Problem oder weiß, wie man das lösen kann?
Wäre für Hilfe dankbar

Grüße

Ich

 

[Michael...]

Muss es unbedingt UDP sein? Ginge nicht TCP?

 

[flash2910]

theoretisch schon - aber es wird so eine art online-game, da ist tcp ja eher schlecht. außerdem kanns das ja nicht sein - bei anderen programmen geht das auch. hat jemand ne idee?

 

[FArt]

Vermutung: der Empfänger ist zu langsam für deinen Sender...

 

[Michael...]

Was heisst so eine "Art" Online Game? Eventuell ist TCP ja doch ausreichend.

Vorweg: Ich hab keinerlei Erfahrung mit UDP, aber UDP ist zwar ein "flaches" aber auch unzuverlässiges Protokoll. Wenn wichtige Informationen ankommen müssen, dann muss man sich selbst darum kümmern, z.B. wichtige Pakete solange und sooft abfeuern bis ein ACK von Client zurück kommt.

Dir mir bekannten Online Ego Shooter nutzen alle aufgrund der Echtzeitrelevanz UDP. Keine Ahnung welche Mechanismen zur Übertragung kritischer Daten da eingesetzt werden.
Aber vielleicht findet sich hier ein Experte...

 

[Andi_CH]

Das hat UDP so an sich, das Daten verloren gehen können - du kannst ja als Übung einen Datensicherungslayer implementieren ;-)
Pakete fortlaufend nummerieren und wenn eines nicht ankommt einfach noch einmal anfordern.

 

[ice-breaker]

wenn Daten wirklich verloren gehen dürfen (wie VoIP, Ego-Shooter) ist UDP sicherlich eine gute Wahl, muss man aber eine Datensicherungsschicht über UDP aufbauen (reliable UDP) kann man auch gleich auf TCP setzen, denn dann hat UDP einfach kaum noch einen Vorteil.

Und ob TCP zu langsam ist, würde ich mal austesten, i.R. sollte es vollkommen ausreichend sein, die Dateübertragungszeit ist das Problem, eher weniger der Protokolllayer.
Wenn bei TCP wenige Datenverluste auftreten ist der Overhead gegenüber UDP auch nur minimalst.

 

[Gast2]

Dir mir bekannten Online Ego Shooter nutzen alle aufgrund der Echtzeitrelevanz UDP. Keine Ahnung welche Mechanismen zur Übertragung kritischer Daten da eingesetzt werden.

was weg ist, ist weg ... nennt sich auch Laaaaaaaag ... wenn - dann "springen" Spieler wild zwischen zwei Stellen in der Map umher ... Spieler wegeben sich stupide gerade aus ... etc. ... der ganze Bewegungskram basiert auf Schätzungen, wo der Spieler sein könnte ... daher funktioniert auch der Autorenn-Mod von HL2 nicht wirklich ... weil da die Schätzungen anders funktionieren müssten

Aber vielleicht findet sich hier ein Experte...

nein - bin ich nicht

 

[flash2910]

hm, danke für die vielen antworten.
das problem is bei mir nicht, dass EINIGE pakete nicht ankommen,
sondern dass nur das erste ankommt, und alle anderen nicht. und das kann man
wirklich nicht auf die arbeitsweise von udp schieben - da läuft ja irgendwo was schief.
wenn der empfänger wirklich zu langsam für den sender ist, kann man das empfangen irgendwie absichern?

 

[Gast2]

sondern dass nur das erste ankommt, und alle anderen nicht.

Dein Empfänger ist zu langsam - oder - Dein Sender ist zu schnell

und das kann man wirklich nicht auf die arbeitsweise von udp schieben

doch - weil genau diese Probleme verursacht UDP :rtfm:

da läuft ja irgendwo was schief.

ja - dein Empfänger ist zu langsam ... am Sender zu Schrauben bringt nichts :bahnhof:

wenn der empfänger wirklich zu langsam für den sender ist, kann man das empfangen irgendwie absichern?

ja - das Verhalten von TCP in UDP programmieren ... in dem Moment wird das mit UDP aber unsinnig - kannst Du auch gleich TCP verwenden :autsch:

 

[flash2910]

doof naja, dann werd ich das wohl doch mit ner kurzen pause zwischen den paketen machen. habs jetzt noch nicht getestet, aber ich denke das problem tritt nur auf, wenn viele pakete sehr kurzzeitig hintereinander an den selben empfänger geschickt werden. bekommen mehrere clients die pakete, die sehr kurz hintereinander geschickt werden, so müsste eigentlich alles funktionieren - oder hab ich da nen denkfehler?

 

[Gast2]

Du solltest evt. Deinen Empfang überarbeiten ... verwendest Du Threads?

 

[flash2910]

tu ich - ich habs jetzt mit kurzen pausen zwischen den paketen für die sendungen gelöst - passiert ja auch nicht die ganze zeit, sondern nur beim connecten mit dem server. ist zwar unschön, aber egal

 

[Gast2]

ich habs jetzt mit kurzen pausen zwischen den paketen für die sendungen gelöst

und das bringt was? ... nix ... was passiert wenn plötzlich alle Clients ein Paket senden ... oder synchronisierst Du die Clients untereinander, so das immer eine gewisse Zeit zwischen allen Paketen von allen Clients existiert? ... damit der Server auch alles verarbeiten kann

am Sender zu schrauben bringt nichts

passiert ja auch nicht die ganze zeit, sondern nur beim connecten mit dem server.

nein - das passiert öffter ... vgl. Murphy

ist zwar unschön, aber egal

mit egal geht die Welt unter

 

[Empire Phoenix]

Hm alos theorie, der router wswtich ect hat nicht genug cahce und droppt einfach alles was nicht reinpasst. (Und ja mit java kann man auch uni router zum abstürzen/ddos bringen, von home routern mal ganz zu schweigen).

Ich würde ein duales system empfehlen, bau zwei verbindungen auf schick per tcp alles wichtige und per udp ales unwichtige, hat die Vorteile aus beiden welten für einen etwas höheren initial aufwand.

 

[Dit_]

Ich arbeite öfters mit UDP, wenn im spiele geht, dann ist UDP die erste wahl. Ohne Pause geht leider nicht, versuche die möglichst kurze Pause durch Testen einzustellen. Die UDP ist so eine art "unfaire" Verbindung, könnte sein, dass Pakete geblockt werden, weiss nicht, könnte vielleicht sein...
evtl muss du dafür sorgen dass die Pakete zu einem "Stream" gehören, vielleicht mal mit DatagramChannel versuchen.

 

[flash2910]

danke für die antworten.

1. mir egal, dass die welt untergeht
2. ich denke nicht, dass der server probleme mit verlorenen Paketen kriegt - es sind maximal 10 Clients geplant. und wenn doch mal eins verloren geht, is das au net soo schlimm - Wichtig sind nur die Daten, die der Server am Anfang an den Client ausliefert (die Map).
3. Glaub nicht, dass das Problem am Router liegt - es tritt auch auf wenn ich Server und Client auf dem selben Rechner laufen lasse.
4. irgendwo oben hat jemand die idee gepostet, eine art überprüfungsroutine für udp zu programmieren. das hab ich jetzt gemacht. der server schickt ein paket und wartet auf die bestätigung - dann schickt er das nächste usw. mein testkollege ist grad nicht da, aber ich denke das geht ganz gut. tcp zu nehmen is doch billig

 

[ice-breaker]

4. irgendwo oben hat jemand die idee gepostet, eine art überprüfungsroutine für udp zu programmieren. das hab ich jetzt gemacht. der server schickt ein paket und wartet auf die bestätigung - dann schickt er das nächste usw. mein testkollege ist grad nicht da, aber ich denke das geht ganz gut. tcp zu nehmen is doch billig

dein verfahren ist deutlich ineffizienter als tcp.
Warum meint jeder das Rad neu erfinden zu müssen ???:L

 

[Gast2]

Warum meint jeder das Rad neu erfinden zu müssen ???:L

weil sonst irgend wann keiner mehr Räder herstellen kann und wir ein ernsthaftes Problem die nächsten 2 Mio. Jahre haben :rtfm: ... ab und zu muss man einfach (aus lerntechnischen Gründen) das Rad neu erfinden

gut - ich erfinde auch mal gerne das Rad neu (aus eben jenigen Grund oben) ... aber TCP auf UDP nachzubauen ist reine Zeitverschwendung und definitiv Fehleranfälliger als das Original ... mal abgesehen davon ist TCP nichts weiter als UDP mit Fehlerkorrektur ... beide Pakete verhalten sich im Netzwerk erstmal exakt gleich :reflect:

 

[ice-breaker]

mal abgesehen davon ist TCP nichts weiter als UDP mit Fehlerkorrektur ... beide Pakete verhalten sich im Netzwerk erstmal exakt gleich :reflect:

bis auf z.B. das Flow-Control mit dem Sliding-Window-Verfahren, den Handshakes und und und

 

[Gast2]

bis auf z.B. das Flow-Control mit dem Sliding-Window-Verfahren, den Handshakes und und und

mit Fehlerkorrektur

TCP Pakete werden erstmal genau so losgejagt wie UDP Pakete ... wenn was schief läuft werden beide Pakete vom Netzwerk weggeschmissen ... und dann greifen die Mechanismen von TCP

 

[ice-breaker]

TCP Pakete werden erstmal genau so losgejagt wie UDP Pakete

werden sie nicht, schau dir mal TCP genau an
TCP hat eine Flusskontrolle um das Überschwemmen des Empfängers wie bei UDP zu verhindern, es dürfen nur eine gewisse Anzahl an unbestätigten Paketen verschickt werden, danach muss der Sender warten, das ganze nennt sich Sliding Window Verfahren und ist eine echt geniale Sache.

wenn was schief läuft werden beide Pakete vom Netzwerk weggeschmissen ... und dann greifen die Mechanismen von TCP

wenn das Paket defekt ist gebe ich dir Recht (falsche Checksumme), wenn die Pakete aber nur in der falschen Reihenfolge kommen greift wieder das Sliding Window Verfahren und ordnet die Pakete beim Empfänger einfach neu.

 

[flash2910]

man erfindet das rad neu, weils spass macht
das tcp protokoll ist bestimmt deutlich besser programmiert als meine in 5 min hingeschusterte methode mit udp, aber dann hab ich es selbst gemacht und das hilft mir mehr, als bei google "java tcp" einzugeben und das zweite suchergebnis aufzurufen, wo bereits ein kompletter code gepostet ist. ich mach das ja auch nicht um geld zu verdienen, sondern um was zu lernen