Ist der Client so gebaut, dass er einen festen lokalen Port verwendet, kann ein zweiter Client auf demselben PC den Port nicht nutzen oder teilt sich die Pakete mit dem ersten.
Warum Zwei Clients wollen denselben lokalen UDP-Port öffnen (per Wiederverwendungsoption gewaltsam geteilt) → Folge Das OS übergibt eingehende Pakete nur an einen Socket oder garantiert nicht, welcher sie bekommt. Auch Router und Server sehen beide Clients unter derselben Adresse → Auf dem Bildschirm Ein Client bekommt keine Weltpakete, NPCs und andere Spieler sind unsichtbar oder es kommt zum Verbindungsabbruch
Client: lokalen Port automatisch vom OS wählen lassen (bind auf Port 0). Server: Verbindungen über ein pro Verbindung ausgegebenes Session-Token unterscheiden.
Im Graphen
Nur einzelne Ausreißer · Empfangene Pakete pro Client
Wo nachsehen
Auf dem PC des Spielers bei laufenden zwei Clients in der Eingabeaufforderung mit netstat -ano -p udp die lokalen UDP-Ports pro Spielprozess (PID) anzeigen. Auf Serverseite prüfen, ob beide Sessions mit derselben öffentlichen IP und demselben Port ankommen
Spricht dafür
Beide Spielprozesse sind an denselben lokalen Port gebunden, oder auf dem Server erscheinen beide Sessions mit derselben IP und demselben Port. Mit nur einem Client normal
Spricht dagegen
Beide Clients nutzen unterschiedliche lokale Ports, und einer verhält sich trotzdem seltsam: „Fehlerhafte Session-Zuordnung nach IP oder Gerät“ oder „Multi-Client-Beschränkung“
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen
Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSEMicrosoft Ein zweites bind auf denselben Port mit SO_REUSEADDR übernimmt den Port, und welcher Socket die Pakete bekommt, ist nicht vorhersehbar
bind function (winsock.h)Microsoft bind auf Port 0 weist einen eindeutigen Port aus dem dynamischen Portbereich (49152–65535) zu
netstatMicrosoft -a zeigt TCP- und UDP-Ports, -n numerische Adressen, -o die Prozess-ID (PID), -p udp nur UDP
Verwandte Ursachen
Gleiche Schicht: Probleme, die nur einige betreffen