# UDP Daten kommen nicht an



## flash2910 (20. Apr 2011)

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... (20. Apr 2011)

Muss es unbedingt UDP sein? Ginge nicht TCP?


----------



## flash2910 (20. Apr 2011)

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 (20. Apr 2011)

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


----------



## Michael... (20. Apr 2011)

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 (20. Apr 2011)

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 (20. Apr 2011)

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 (20. Apr 2011)

Michael... hat gesagt.:


> 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 (20. Apr 2011)

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 (20. Apr 2011)

flash2910 hat gesagt.:


> 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 (20. Apr 2011)

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 (20. Apr 2011)

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


----------



## flash2910 (21. Apr 2011)

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 (21. Apr 2011)

flash2910 hat gesagt.:


> 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



mogel hat gesagt.:


> 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 (21. Apr 2011)

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_ (21. Apr 2011)

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 (22. Apr 2011)

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 (22. Apr 2011)

flash2910 hat gesagt.:


> 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 (22. Apr 2011)

ice-breaker hat gesagt.:


> 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 (22. Apr 2011)

mogel hat gesagt.:


> 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 (22. Apr 2011)

ice-breaker hat gesagt.:


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





mogel hat gesagt.:


> 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 (22. Apr 2011)

mogel hat gesagt.:


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



mogel hat gesagt.:


> 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 (23. Apr 2011)

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


----------

