spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ja.

Pro Port halt ein Socket.

Dass es geht, weißt du ja nun. Rein aus Neugier: cui bono?

Bevor du mit mehreren threads rumspielst, lies dich vorher lieber in die Materie ein!
Eine Funktion mit mehreren threads auszuführen geht, dafür braucht die nicht "instanziert" werden (das gibt es so für Funktionen eh nicht)!

Die Faustregel ist das mehrere threads von einer Variable oder Speicherstelle lesen können, da kann es nicht zu race conditions kommen... Der Speicher ändert sich ja nicht. Problematisch wird es wenn du einen thread hast der schreibt, weil dann kann es zu race conditions kommen. Das Problem ist das du unter umständen threads hast die versuchen zu lesen während ein anderer schreibt, oder zwei threads die schreiben. Je nachdem wie das Betriebssystem den threads CPU Zeit zuweist, kann das super gut gehen, oder dafür sorgen das du Variablen falsch einliest oder beschreibst (*)

Das ganze nur als grobe Übersicht, ausreichend um deine Frage zu beantworten. Aber noch nicht ansatzweise genug um wirklich multithreading zu machen! Das riesen Problem ist das es nicht deterministisch ist, und das kann 1000e läufe auf deinem Computer gut gehen und dann auf jedem Kunden Rechner kaputt gehen. Here be dragons!

(*) Dabei ist zu beachten das x86(-64) ein usually strongly memory ordering hat, sprich das du ein _bisschen_ atomic verhalten bekommst. Es ist keine strongly ordered memory Architektur, erlaubt aber mehr Dinge als weakly ordered memory ordering wie PPC oder ARM.

Edit: Du brauchst nicht für jeden port einen thread! Wenn es um ein Spiel geht solltest du eine run loop haben in der du deine ports fragen kannst ob sie Daten haben und die dann einlesen. Non-blocking I/O wäre hier das google Stichwort.

Warum brauchst du 5 verschiedene Ports?

Der OS Kernel wird dir schon die Daten vorbehalten und nicht sofort wegwerfen wenn du sie nicht innerhalb der nächsten 5ns liest. Stream heißt nicht das du die Daten sofort empfangen und verarbeiten musst und ansonsten sind sie weg, der unterschied zwischen SOCK_STREAM und SOCK_DGRAM liegt im Protokoll und wie die daten konsumiert werden.
Stream sockets erlauben es dir Daten als beliebige byte Sequenzen zu lesen, sprich du kannst zbsp. 5x 40byte senden und das ganze als ein 200byte blob lesen, wohingegen Datagram sockets dich dazu zwingen auch wieder 5x 40 bytes zu lesen. Ansonsten ist halt noch der Unterschied das bei SOCK_STREAM, und daher TCP, die bytes in der Folge rausfallen wie sie reingefallen sind, und SOCK_DGRAM die die Datagramme in beliebiger Reihenfolge gibt (falls sie überhaupt bei dir ankommen).

Lustig das sich UDP viel besser dafür eignet "wirkliche" streams zu bauen