# Welche Art von Sockets für ein Spiel?



## Progman (20. Nov 2004)

Hallo

Ich spiele mit dem Gedanken ein Kartenspiel zu programmieren. Ich frag mich nun, wie ich die Verbindungen, die von den Clients kommen, verwalten soll. Ich habe mir 2 Möglichkeiten ausgedacht.

 Die accept-Methode vom ServerSocket packe ich in ein Thread, sowie alle Verbindungen zu den Clients. Damit kann ich dann im 'Hauptteil' mein Spiel verwalten und reagiere auf Ereignisse in den Threads (ist dies möglich? wenn ja, wie kann man sowas realisieren?)
 Ich habe was über Channels gelesen, nur irgendwie ist mir das System noch nicht so ganz vertraut. Über die select-Methode eines ServerChannels krieg ich irgendwie, das sich was an den Sockets getan hat. Somit brauch ich keine eigene Threads, da select mit einem Timeout schon fast wie ein Thread agiert und ich das Spiel weiterhin im Hauptteil verwalten kann.
Und wie sieht das für den Client aus. Soll ich da so wie beim Server auch die Verbindung in ein Thread packen oder soll ich da auch die Channels benutzen.

Wenn ich euer Meinung nach Channels benutzen soll, könnt ihr mir Informationen über Channels geben. Denn das System hab ich noch nicht so ganz verstanden, weil da mehrere Sachen wie Selectoren und Iteratoren ineinandergreifen.

mfg Progman


----------



## DTR (27. Nov 2004)

Hallo,

ich würde die Kommunkation über zwei Threads, einen Server und einen Client Thread laufen lassen. Ein Spieler muss dann als Server auftreten, und die anderen als Clients. Das Spiel läuft dann eigendlich beim Server und die Client kümmern ishc um die jeweiligen Ausgaben.


----------



## Progman (28. Nov 2004)

Da hast du was falsch verstanden:

Wie realisiere ich die Verwaltungen der Clients beim Server? Die Server- und Clientprogramme lasse ich schon getrennt verwalten, das ist nicht das problem. Was das problem ist, wie ich die Verbindungen verwalte.

Beim Server:
Er muss ja jede Verbindung speichern und auf Ereignisse reagieren. Das problem ist, dass ich nicht einfach spieler1_socket.read(); (sinngemäß) machen kann, denn dann würde er den Programmfluss blocken, bis Spieler 1 etwas zum server schickt. Deswegen habe ich mir überlegt das ich diesen Methodenaufruf in einen Thread packe und ich im Hauptteil des Serverprogramms sowas wie spieler1.hasSaySomething() realisiere, das Abfragt, ob der Client etwas gesendet hat und ich es auslesen kann. Somit habe ich für jeden Spieler bzw. jede Verbindung ein Thread laufen, der auf den Socket horcht und die ganze zeit darauf wartet, bis ein Spieler etwas sendet.

Jetzt gibt es aber auch diese neue Technik mit den Channels. Da wird in einem Selector (was immer der auch macht und was immer das auch ist) die Verbindungen gespeichert und das Programm liest dann in diesen Selector aus, wann sich etwas an den Sockets getan hat. Diese Channels übernehmen dann für mich die Aufgabe der Threads und ich kann ohne Threads im Hauptprogramm mein Spiel weiter verwalten, nach dem Motto "Hat sich was an den Verbindungen getan? nein? nagut, dann weiter im Spielverlauf...".

Die gleiche Entscheidung muss ich bei den Client wählen, aber da brauch ich zum Glück nur eine Verbindung verwalten, nä(h)mlich die zum Server.

Und nun die Frage, welche Technik ich nehmen soll? Soll ich mit Threads arbeiten und jede Verbindung in ein Thread packen oder soll ich diese Channeltechnik benutzen? Wenn ihr meint, ich soll die Channeltechnik mit ServerSocketChannel, SocketChannel, Selector und Iterator benutzten, könnt ihr mir Informationen über diese Technik geben?


----------



## DTR (29. Nov 2004)

Im prinzip ist es egal, ob du zu jedem Client einen eigenen Socket öffnest oder einem SocketChanel pro Client. Meiner ansicht nach musst du beides irgendwie beim Server verwalten. Am ende kommst du um Threads nicht drumrum, da sich die Client sonst gegenseitig aufhalten. Den für die Chanels benötigte SelectorProvider musst du auch noch schreiben. Mit Chanels kann man es wohl sauberer Schreiben.


----------

