Hi!
Ich bin in Sachen Netzwerkprogrammierung noch nicht so bewandert und habe hierzu auch gleich eine Frage. Und zwar zur Lobby-Programmierung. Jeder, der schonmal ein Multiplayergame gezockt hat, kennt den üblichen Ablauf:

1. Der Host (Host0) erstellt ein Spiel
2. Der Client klickt auf "Spiele suchen" und findet das Spiel des Hosts, ohne je eine IP oder einen Port eingegeben zu haben.

Beim Spielen im Internet ist sowas ja relativ leicht zu realisieren: Der Host trägt sich in eine Liste ein, die auf einem "immer" erreichbaren Server des Spielepublishers gespeichert ist. Der Client ruft die Liste einfach ab und weiß daher die Verbindungsdaten.

Dass das ganze aber auch im LAN und zwar völlig ohne Internetverbindung klappt, kann ich mir nicht wirklich erklären.

[Theorie, nicht so wichtig]
Ein Ansatz wäre, dass das Spiel grundsätzlich Port 12345 verwendet. Der Host bindet diesen Port und wartet auf eingehende Verbindungen. Der Client nimmt sich seine eigene IP (sagen wir 192.168.0.2) und geht alle Möglichkeiten der letzten Stelle durch (also 192.168.0.1 - 192.168.0.255) und versucht sich mit denen über Port 12345 zu verbinden (ausgenommen ist natürlich die eigene IP). Scheinbar spielt die Subnetzmaske (255.255.255.0) hier eine Rolle, denn es werden nur die Stellen variiert, die 0 sind.

Allerdings wird das in der Praxis bestimmt anders gemacht, denn das beschriebene Verfahren weist einige Schwächen auf:

• Wenn ein zweiter Host (Host1) kommt, kann er Port 12345 nicht binden, da er schon vom ersten Host besetzt ist. Natürlich könnte man tricksen: Er weicht auf einen anderen Port aus, teilt diesen Host0 mit. Wenn wieder ein Client auf der Suche nach Servern ist, teilt Host0 neben seiner Existenz auch jene von Host1 mit. Allerdings wäre Host1 dann nicht mehr erreichbar, sobald Host0 unerwartet vom Netz getrennt wird...
• Man stelle sich vor, für jedes laufende Online-Spiel wird ein kompletter Port blockiert. Von den verfügbaren 65536 wäre dann wohl nie einer frei.

[/Theorie, nicht so wichtig]

Die Netzwerkspiele, die ich kenne, haben nicht mit solchen Problem zu kämpfen. Daher meine Frage: Wie realisiert man das Offenes-Spiel-finden in der Praxis?

Danke schonmal für jede Hilfe!

mrtrain

Versuch das doch mal, bei 192.168.0.255 wird dir etwas "auffallen".
Das ist nämlich die Broadcast Adresse. Wenn du an diese etwas schickst, bekommen ALLE Adressen im 24-Subnetz die Nachricht. Und so funktioniert es in der Regel auch. Ein Server broadcastet in einem gewissen Takt < 1 Sekunde, dass er da ist und gibt Informationen preis, u.A. seine IP.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Danke, das ist gut zu wissen. Was meinst du mit "24-Subnetz"? Alle Geräte mit einer 192.168.0.*-IP?
Äh, er broadcastet, soso. Muss man dazu irgendetwas spezielles machen? oder geht das automatisch, sobald man listen() aufgerufen hat?

Was ist mit dem Port-Problem, also (wie) ist es möglich, dass ein bestimmtes Spiel mit wenigen Ports auskommt, obwohl davon mehrere Partien paralell zueinander laufen?

Thx
mrtrain

Ja
Äh, er broadcastet, soso. Muss man dazu irgendetwas spezielles machen? oder geht das automatisch, sobald man listen() aufgerufen hat?[/quote]
Im Detail kenn ich mich Programmiertechnisch kaum aus, aber ich denke so müsste das funktionieren.

Zum einen kannst du neben TCP/UDP dein "eigenes" Protokoll basteln, also z.B. in jedes Paket schreiben, um welches Spiel es sich handelt. Eine andere Möglichkeit ist, dass über Port 12345 verbunden wird und der Host dann für das konkrete Spiel einen neuen freien Port wählt.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Bevor das hier böse schief geht …
Also, die Broadcast-Adresse kannst du im LAN niemals sicher auf 192.168.0.255 pinnen (aus dem gleichen Grund ist auch deine Theorie nicht so sinnig ). Die musst du zuerst irgendwie herausbekommen. Oder du schickst pauschal an 255.255.255.255 (dann aber bitte mit einer passenden TTL).

Dann: Du kannst auf keinen Fall per TCP broadcasten. Das geht (einfach) nur mit UDP. UDP baut keine Verbindungen auf, sondern schickt wild ins "Leere". Du kannst dann auf einem spezifischen Port (z.B. eben 12345) auf solche Pakete "horchen". Ein Host könnte dann solche Pakete mit seiner IP (wie Ziz schon angedeutet hat) und irgendeiner Signatur, damit du erkennst, dass es sich auch um einen Host zu deiner Anwendung handelt, verschicken.
Wenn du dann so ein Paket empfängst, kannst du damit arbeiten, indem du die IP z.B. in deine Liste einträgst. Zusätzlich zur IP könntest du auch noch den Port mitschicken etc.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich habe mir nun ein paar Sachen zu Broad- und Multicast durchgelesen. Da hat sich mir die Frage gestellt, warum bei UDP überhaupt noch ein Port gebunden werden muss, wenn sowieso keine Verbindung mehr vorhanden ist. Warum würde es nicht reichen, wenn z.B. der Host recvfrom() aufruft und darauf wartet, dass ein Client ein sendto() an 255.255.255.255 macht? Oder andersrum. UDP verwirrt mich irgendwie.

Weil du als Lobby wahrscheinlich nicht den Traffic von einem Mumble-Server empfangen willst und umgekehrt . Die Ports erlauben das aufteilen nach Anwendung, zumindest mehr oder weniger. UDP sind halt mehr oder weniger rohe Pakete, die du verschicken kannst.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Schon klar, dass das Aufteilen Sinn macht. Aber wenn man recvfrom() aufruft, gibt man als Parameter doch sowieso den Port an.

Ein UDP Paket besteht aus einem IP Header, einem UDP Header und den UDP Daten.

Im IP Header stehen Quell- und Zieladresse.
Im UDP Header stehen Quell- und Zielport.
Du brauchst also garnicht die Lobby IP in den Daten unterbringen.

Die Broadcast-Adresse erhält man indem man die eigene IP mit der Subnetzmaske logisch mit UND verknüpft und den dadurch maskierten Host-Anteil mit 1 auffüllt. Wobei ich mal davon ausgehe, das Funktionen zum Senden an die Broadcast-Adresse in einer guten Komponente schon verbaut sein dürften. Ich meine mich zu errinnern, dass z.b. die Indy-Kompos sowas hatten.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

So, ich melde mich nochmal zu diesem Thema zurück. Habe ein wenig rumprobiert, allerdings funktioniert das mit dem Broadcasting noch nicht so ganz. Daher noch ein paar Fragen:

Wer muss / sollte nun eigentlich den Port binden? Host oder Client, Empfänger oder Sender?
Wie sagt man Winsock die TTL?

Aktueller Stand ist, ich habe ein kleines schmuckloses Programm, mit dem ich per ButtonClick sendto() an die Adresse 255.255.255.255 sende. Vorher aktiviere ich noch Broadcasting:Der Returnvalue von sendto() liefert jetzt auch Erfolg.

Des Weiteren habe ich einen RecvButton, der den Port bindet (funzt auch, Firewall fragt nach etc.), allerdings liefert das darauffolgende recvfrom() -1 alias SOCKET_ERROR zurück, ohne dass WSAGetLastError() etwas zu meckern hat.

Blödes UDP - TCP war irgendwie einfacher. Allerdings nützt mir das hier wenig, also werde ich wohl kaum um UDP herumkommen.

Thx 4help

mrtrain