2 Threads pro Client im Netzwerk - sinnvoll?
-
Hallo, ich frage mich nun schon seit längerer Zeit, ob es sinnvoll ist, 2 Threads pro Client zu erstellen, einer zum Senden und der andere zum Erhalten von Nachrichten!
Was sagt ihr dazu?mfG Ich
-
was versprichst du dir davon?
und vorallem: worum geht es?
-
Wenn es um MFC geht dann macht dies die Klasse CAsyncSocket für dich.
Wenn nicht dann macht es durchaus Sinn einen extra Thread zu verwenden da man GUI von Code trennen sollte.
Thread für Send und einen für Read macht nur Sinn wenn man sie syncronisiert (muss man ja eigentlich eh) da man nur ein Socketobjekt hat.
-
Es geht um ein Spiel. Es ist eine Art Brettspiel, bei dem abwechselnd gezogen wird. Ich überlege daher schon die ganze Zeit, ob es nun sinnvoll ist, durchgehend etwas zu senden oder nur bei Bedarf (z.B. Statewechsel oder Zug) gesendet werden soll.
Ich verspreche mir davon, dass das Senden nich durch das Warten auf Nachrichten behindert wird
-
DasPinscht schrieb:
Ich verspreche mir davon, dass das Senden nich durch das Warten auf Nachrichten behindert wird
einfach nicht blockend lesen?
-
Dein Programm muss vier Sachen gleichzeitig machen:
1. Eingaben vom Benutzer erwarten
2. Dem Benutzer eine Ausgabe liefern
3. Daten über das Netzwerk verschicken
4. Daten über das Netzwerk empfangenDie beiden einfachsten Wege, damit umzugehen, sind IO-Multiplexing via select oder Threads. Da ich normalerweise Threads als den einfachsten Weg empfinde, nehme ich diese in solchen Fällen.
-
Die erste Frage, die ich mir beantworten muss, ist, ob kontinuierlich Daten gesendet werden sollen, oder nur wenn dies erfordlerlich ist. Das 2. erscheint mir sinnvoller, allerdings entstünde dann das Problem, dass es schierig zu testen ist, ob ein Socket noch verbunden ist. Gibt es dafür eine Funtkion?