Kurz:
*) PB-Netzwerkfunktionen nur in einen Thread verwenden (muss nicht der Mainthread sein)
*) In die "Empfangs-schleife" muss nicht nur ReceiveNetworkData() rein sondern ebenso - und das ist wichtig - Network[Client|Server]Event(). Also nicht lediglich einmal checken ob was ansteht und dann wiederholt mit ReceiveNetworkData() saugen sondern wirklich immer Network[Client|Server]Event() zusammen mit ReceiveNetworkData() in die Schleife rein. Fehlt das Network[Client|Server]Event() fehlt das select() und das heißt bei Blocking sockets daß sie bei 'nem recv() blocken werden bis wirklich Daten kommen.
Lang:
Das Problem mit der Netzwerklib von PB ist daß sie Serverseitig mehrere (an und für sich getrennte) Socket-funktionen in eine zusammenwurstelt. Damit ist sie z.B. denkbar ungeeignet um damit eigenständge Client-Threads zu machen die nur auf ihren Socket hören sollen. In PB würde dank des zusammenmischen ein Client-Socket die Events von den anderen stehlen und darüber hinaus auch noch gleich die Events vom Listening-Socket. Das heißt das was normalerweise locker 3 oder mehr Threads sein könnten die getrennt voneinander arbeiten ohne sich ins Gehege zu kommen muss in PB eigentlich ein und der selbe Thread sein und die Events müssen manuell zerlegt werden. Warum? Weil man dort wo man mit normaler Socket-Programmierung eigentlich ein accept() auf den Listening-Socket machen kann (z.B. eigener Thread) und später ein select() auf den Client-Socket (und nur auf diesen in einem anderen Thread) und darüber hinaus möglicher aber nicht notwendiger Weise vielleicht sogar ein ioctlsocket() mit FIONREAD um zu erfahren wieviel man vom Eingangspuffer mit recv() erwarten kann gibt's in PB nur eine Funktion. Das wiederum heißt daß es auf der Serverseite rein mit PB-Netzwerkfunktionen keine reine "Ich empfang jetzt nur mal Daten so lange da welche anstehen - Empfangsschleife" gibt die nur einen Client bedient. Du machst da eigentlich immer eine "Empfang ein paar Daten und check alle Sockets ob die vielleicht auch Daten anstehen haben und check den Listening-Socket ab ob neue Clients connecten und dann Empfang wieder ein paar Daten" Schleife. Dabei finde ich es interessant zu erwähnen daß man mit normaler Socket-Programmierung einen sauberen Disconnect eigentlich dann signalisiert bekommt wenn recv() (also die Funktion die eigentlich Daten empfängt) 0 zurück gibt... was ja eigentlich durchaus Sinn macht (in einer solchen PB-Mix-Schleife allerdings ziemlich komisch kommt).
Lösung die auch mit PB super funktioniert
https://en.wikipedia.org/wiki/Berkeley_sockets