Intelligentes TCP-Server Design

Hey,

ich habe vor ein einfaches Go (Brettspiel) Server/Client System zu entwickeln.
Dabei stell ich mir vor, dass zu dem Paket ein Server und eine Library gehört um mit diesem zu kommunizieren, d.h. man ohne Probleme Klienten entwickeln kann.

Nun stell ich mir die Frage wie man so einen Server am besten designed. Mein momentaner Gedanke dazu sieht wiefolgt aus:
Der Server-Prozess erstellt einen Socket auf dem er für neue Verbindungen lauscht, weiterhin erstellt er nen epoll fd und packt da den Lausch-Socket und alle Client-Verbindungen rein und wait'ed dann bis irgend ein Socket ready ist.
Wenn ein Client Ready ist soll der Prozess den fd an einen ThreadPool übergeben, der diesen fd dann abarbeitet, d.h. Daten holt, verarbeitet und ggf. antwortet.

Was haltet ihr von diesem Konzept? Bis auf ein paar Ein-Prozess-Server mit select() hab ich mich mit diesem Thema nicht weiter beschäftigt, ich hoffe ihr könnt mir weiterhelfen.

der gofan!

FrEEzE2046

Wie genau soll die Client/Server - Beziehung denn aussehen? Wie viele Spielsessions willst du denn zu lassen? n : 1 oder n : n Verbindungen?
Das wären prinzipiell so ein paar Fragen, die du auch dir beantworten solltest.
Ansonsten: Was soll ich sagen? Es soll ein Server sein?! Also lauscht du auf dem entsprechenden Port und lässt Clients connecten. Was du mit denen machst, hängt ganz von den obigen Fragen ab.

C++ Forumbot

Dieser Thread wurde von Moderator/in Nobuo T aus dem Forum ANSI C in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

FrEEzE2046 schrieb:

Wie genau soll die Client/Server - Beziehung denn aussehen? Wie viele Spielsessions willst du denn zu lassen? n : 1 oder n : n Verbindungen?
Das wären prinzipiell so ein paar Fragen, die du auch dir beantworten solltest.
Ansonsten: Was soll ich sagen? Es soll ein Server sein?! Also lauscht du auf dem entsprechenden Port und lässt Clients connecten. Was du mit denen machst, hängt ganz von den obigen Fragen ab.

pro Spieler nur eine Verbindung, das ist aber auch kein Problem das später zu überprüfen. Momentan stell ich mir einfach Fragen wie blocking oder nonblocking? select, epoll, kqeueue? threads? Wie nach Timeouts ausschau halten? etc.

Das ich auf dem Port lauschen muss is mir klar, und dein "Es soll ein Server sein?!" umgeht ja quasi die ganze Problematik

Athar

Deine bisherige Vorgehensweise ist doch in Ordnung?
Und wie viele Clients erwartest du überhaupt? Selbst mit der "Billigversion" (ein Thread für alles, Verbindungen mit select und sofortigem Timeout einzeln pollen) dürftest du schon ein paar Tausend Clients bedienen können.
Denn sonst dürfte außer der Überprüfung der Spielzüge auf Gültigkeit rechentechnisch nicht viel anfallen.

Ok,

wie handel ich denn am besten das gucken nach timeouts?
wie muss ich meine funktionen gestallten damit das ganze threadsicher wird? ich meine ich bau mir dann ja structs ala player, game etc. und hab dann ja auch funktionen um mit denen zu arbeiten, was muss man da beachten?

greetz, gofan