Hallo zusammen.
Schön, dass hier gerade so intensiv über Netzwerk-Programmierung getalkt wird. Da schalte ich mich nur zu gerne ein, da ich in den letzten Tagen auch an so etwas rumgefummelt habe. Und ich bin auch mittlerweile zu einem Status gelangt, dass eine Kommunikation
in beide Richtungen stattfindet. Das war allerdings ein nicht ganz unsteiniger Weg. Ich möchte, da das von Interesse sein könnte, einmal ein paar Punkte nennen, die mich erheblich weitergebracht haben. Eventuell hat auch zu meinem Ansatz ja noch jemand Ideen
oder Verbesserungsvorschläge. Ich bin so vorgegangen:
- Server und Client sind zunächst unterschiedliche Klassen in unterschiedlichen Anwendungen (theoretisch könnte aber ein Client auch ein Server darastellen)
- Client wie auch Server bauen einen TCP-Listener auf, auf einem vorher definierten Port
- Client loggt sich beim Server ein, indem er eine Verbindung aufbaut und der Server diese annimmt und speichert (Wichtig: jeder Client bekommt einen neuen Thread. Die Rückgabe "Client" von TCPAcceptClient beim Server wird also direkt an einen neuen Thread
weitergegeben, der dann die eigentliche Verbindung behandelt)
- Will der Client etwas schicken, wird es nun mit diesem Thread empfangen. Nach erfolgreichem Empfang, und einer gewissen Karenzzeit, wird der Thread verworfen und die Verbindung wieder abgebaut. Jede Nachricht erzeugt also einen neuen Thread.
- Wenn der Server eine Nachricht empfängt und das erste Mal eine Verbindung aufbaut, merkt er sich die IP des Senders. Sobald ein "LOGON" kommt als Nachricht, speichert er zudem den Status, dass dieser User eingeloggt ist. Hier kann wahlweise natürlich auch
weitere Daten geschickt werden, Username, Passwort, was auch immer.
- Sollte der Server selbst entscheiden, dass eine Aktualisierung nötig ist, die z.b. von einem Client kommt, und an andere verteilt werden soll, so sind ja über das "LOGON" alle Clients registeriert. Dann wird eine Nachrichtenkette initialisiert (über die
sowieso alles läuft bei mir), und in diese werden an jeden Spieler eine Nachricht gehängt. Damit diese verschickt werden kann muss der Client auch einen TcpListener haben. Hier gilt im Grunde das selbe Prinzip: ein Listener, der bei jeder einkommenden Nachricht/Verbindung
einen neuen Thread öffnet, der diese Nachricht empfängt und abspeichert. Im Listener wird dann auch die weitere Verarbeitung intialisiert.
- Sollte einmal eine Verbindung abbrechen, so stürzt ja entweder der Thread ganz ab (das ist aber wurscht), oder nur ein Stream wird unterbrochen. Dieser Streamabbruch wird mit Try/Catch behandelt und dann an den jeweiligen Host zurückgegeben per Event.
Der kann dann entscheiden, ob die Verbindung erneut aufgebaut werden soll. In meinem Fall bekommt erst bei vollständigem Senden die Nachricht ein "Sent"-Flag und verbleibt bis zum erhalt dieses Flags in der Queue. Sie wird also im Zweifelsfall erneut geschickt.
Auch beim Empfänger wird sie erst verarbeitet, wenn sie komplett ohne Verbindungsabbruch empfangen wurde. Hier wird auch ein Fehler erzeugt, und die empfangene Teilnachricht verworfen, wenn der Stream abreißt.
- Zusätzlich sende ich in gewissen Intervallen eine Art Ping (im Moment der Performanz und Benutzerfreundlichkeit zuliebe alle 30 Sekunden), um die Verbindung zu prüfen, ob der Server überhaupt noch erreichbar ist, bzw. der Client. So kann der Client
einen (um das hiesige Beispiel aufzugreifen) benachrichtigen, dass man vom Server "geflogen" ist, oder der Server ein TimeOut generieren, bei dem man automatisch ausgeloggt wird. So würde man nicht direkt aus dem Spiel geschmissen, nur weil eine Nachricht
mal kurz nicht übermittelt werden kann.
Insgesamt war es ziemlich viel gefummel, eine richtige - für beide Seiten "initiierbare" - Kommunikation aufzubauen. Man muss bedenken, dass man erstmal nur "Verbindungen" aufbaut, die einseitig initiiert werden. Außerdem ist man bei der Programmierung für
das komplette Protokoll selbst zuständig.
Also denn ... happy coding!
LG, Dennis.
VB.Net: Kommunikationslösung gesucht (für Networking Null-Niveau)
