spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Is natürlich alles auch eine Firewall-/Router-Frage, ob da was wo ankommt.

Zitat von »LukasBanana«

Aber noch eine andere Frage: Da UDP ja ein Verbindungsloses Protokoll ist, sollte ja auch jeder Client in der Lage sein,
jedem anderen Client direkt eine Nachricht zu schicken, ohne Umwege über den Server, oder!?

Um...ja, sobald der Client die IP vom Server kennt. Und was genau meinst du mit Umwegen?

Achso, ja natürlich. Deine Clients könnten aber auch untereinander TCP Verbindungen aufbauen...
TCP und UDP sind einfach zwei grundverschiedene Dinge. In erster Linie solltest du dir mal überlegen ob du eine sichere Verbindung brauchst oder nicht. Mit UDP kann auch mal ein Paket nicht ankommen. Mit TCP kommt dagegen, wenn nur irgendwie möglich, alles an und das auch noch in der richtigen Reihenfolge (mit UDP ist natürlich auch die Reihenfolge in der Pakete ankommen undefiniert)...

Zitat von »LukasBanana«

Eben nur nicht, ob bei UDP jeder Client jedem anderen Client direkt Nachrichten schicken kann, weil das ja - wie bereits erwähnt - bei mir noch nicht geklappt hat.

Ja klar geht das.

Zitat von »LukasBanana«

In "Quake III" wurde z.B. UDP verwendet, wie das mit aktuellen Spielen ist weiß ich nicht. Wenn eine Spieler-Position in einem Frame mal nicht übertragen wird, macht das nichts.

Hängt vom Spiel ab. Bei einem Shooter wird man UDP verwenden, bei einem RTS dagegen wohl evtl. TCP.

Zitat von »LukasBanana«

Denn dafür ist UDP deutlich schneller als TCP.

Ist das so? Ich würde mal sagen das hängt auch wieder stark davon ab was genau man tut. Wenn du dir in deinem UDP basierten Protokoll am Ende erst wieder alle möglichen Methoden implementieren musst, um sicherzuerstellen dass Pakete auch ankommen, wirst du z.B. am Ende nicht wirklich was gewonnen haben, vermutlich sogar eher im Gegenteil...

Moment ich glaube hier existiert ein kleines Missverständnis:
Man nutzt UDP zum Finden anderer "Spieler" in einem lokalen Netzwerk, weil man hier einfach Nachrichten an alle "erreichbaren" Computer senden kann (das so genannte Broadcasten). Angenommen dein Netzwerk würde aus 3 PCs bestehen (IPs sind 192.168.0.5, 192.168.0.6,10.0.0.1) und auf allen drei würde dein Programm auf den UDP Port 86567 laufen. Nun will der erste PC die anderen finden/fragen ob sie einen Server auf haben. Da er die IPs der anderen nicht kennt kann er auf das Broadcasten zurückgreifen (was es bei TCP nicht gibt), indem er beim Senden z.B. die IP 192.168.0.255 als Empfänger angibt. Die 255 steht dafür, dass sich alle PCs mit einer 192.168.0.x IP angesprochen fühlen. Somit können sich die beiden ersten PCs finden, aber der dritte bekommt nichts mit da er eine 10.0.0.x Adresse hat. Wenn der Broadcast aber an 255.255.255.255 geht, dann empfangen es alle.

Kurzfassung: Programm auf allen Rechner starten, suchende PCs schicken eine Anfrage an 255.255.255.255, antwortende PCs antworten auf die per recvfrom empfangene Adresse.

(Anmerkung: die Adresse 0.0.0.0 ist die Adresse an die man binden muss, wenn man von allen Interfaces Pakete erhalten will; habe ich im letzten Post durcheinander geworfen).

EDIT: dot hat definitiv recht. Nicht selten ist sogar TCP "schneller" (bessere Ausnutzung der Bandbreite); Siehe dazu mein kleines Testprojekt. UDP ist nur dann im Vorteil wenn ein Netzwerkmodell genutzt wird, was Paketverluste gut verkraftet und ohne Neusenden klarkommt.

Zitat von »LukasBanana«

2.) Wenn ich zum broadcasten 255.255.255.255 angebe, ist das nicht etwas ineffizient? Ich hätte jetzt mal an 192.168.255.255 gedacht, da in einem lokalen Netzwerk ja normalerweise immer 192.168.x.x verwendet wird.

Broadcasts werden von Routern üblicherweise (Standardeinstellung) nicht nach aussen geleitet, sondern nur im lokalem Netzt gesendet.