View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide

UDP

Da UDP ein verbindungsloses Protokoll ist, muss man sich selber um die Identifizierung kümmern. Üblich, aber wohl nicht Pflicht, ist die Auszeichnung jedes Paketes mit Absender-IP und -Port. Die Verbindungen können mit netcat / nc getestet werden.

Beispiel: Server - Netcat

nc -u 127.0.0.1 7777

verbindet mit UDP auf localhost, Port 7777 (bzw. Verbindet NICHT, da UDP verbindungsfrei ist.) Netcat sucht sich einen freien Port als Ausgang aus (z.b. 2345).

Der Server wartet auf Port 7777. Der User tippt
nc -u 127.0.0.1 7777
Hallo Server!

Der Server bekommt auf 7777 sein Paket "Hallo Server", Absender 127.0.0.1:2345. Der Server antwortet "ACK" mittels 7777 an 2345. nc gibt aus:
nc -u 127.0.0.1 7777
Hallo Server!
ACK


PHPNetcat
hört7777<*(2345)
sendet7777>?2345>7777

In PHP muss der Server um zu antworten den Socket für Port 7777 auf IP 127.0.0.1:2345 "connecten" (obwohl UDP ja keine Verbindungen kennt...) um sein "ACK" zu senden. Das "connecten" wird also von PHP simuliert, der Socket empfängt und sendet fortan nur noch von/an 127.0.0.1:2345:

PHPNetcat
hört7777<23452345<7777
sendet7777>23452345>7777
Nach dem Absetzen der Nachricht schliesst man den Socket und nimmt einen frischen, der wieder unspezifisch horcht. Was passiert, wenn in der Zwischenzeit ein anderer Client anfragt? UDP ist mit keinerlei Flusskontrolle ausgestattet, also NICHTS.


Also senden wir doch mit Port 7778 und lassen 7777 offen höhren. Doch jetzt ist Netcat eingeschnappt: Er horcht ja nur auf Port 7777, und das ihm eine nachricht an seinen Port 2345 geschickt wird, ignoriert er wohlwollend, sie kommt ja nicht von seinem "Partner" 7777:
PHPNetcat
hört7777<23452345<7777
sendet7778>23452345>7777
Netcat und PHP haben eine etwas zu Verbindungs-denkende Sichtweise...

In Java sieht das etwas anders aus. Hier ist der DatagramSocket ein Socket, der ausdrücklich nicht an eine Zieladresse bindet. Wenn man ein Paket verschickt, so muss es IP und Port enthalten, jedesmal aufs neue. Dadurch kann man weiterhin auf Port 7777 lauschen, ohne Daten zu verlieren (solange sie notfalls kurz gepuffert werden..)


Mit PHP ist kein zuverlässiger Server in einem Port machbar, mit zwei Ports dagegen funktioniert es. Dafür schliesst man die Standardtools z.B. netcat, aus, fraglich ob Simple3D-Client funktioniert.
Bei Java bleibt noch die Sorge, ob wirklich kein Paket verlorengeht, wenn man gerade sendet und damit nicht in der Empfangsfunktion wartet (Puffer?).



da das alles etwas kompliziert ist, habe ich auf vis den syslogd angestellt: er horcht auf :7777 (broadcast/unicast) [und wirft auf :7778 alle wieder heraus (untested)]

t20070513-0235

Clipboard01.jpg


UDP in C: http://www.c-worker.ch/tuts/udpcl.c

Link to this Page