Zum Thema ID, die Lösungen die ich beim Überfliegen gesehen habe sind alle recht langsam und viel zu kompliziert gedacht.
Der Server legt die ID an und diese kann er über die eindeutige Speicheraddresse von dem Objektdaten nehmen.
Ich benutze ein 64Bit große variable, welche den pointer rein gibt und dann als 64Bit zahl wieder raus bekommen kann und anders rum.
So benötigt man keine komplexen berechnungen, prüfungen und so weiter.
Diese IDs sind pro Server einzigartig.
Der schöne Vorteil daran ist, man spart sich das suchen von Objekten, Spielern und so weiter in Listen, da bei einem Event die ID mit kommt und man diese ja sofort in die Speicheraddresse zurück wandeln kann. Man muss dabei beachten, dass man sicher geht, dass keine ungültigen IDs kommen, dies kann man z.B. durch das hinzufügen der ID am Anfang der Daten und dem Prüfen ob der Pointer auf einen Wert zeigt, der den selben wert wie der Pointer hat. Wenn nicht, dann ist es eine ungültige ID.

Thick server and thin client
Das Prinzip setzt sich immer mehr durch bei Office Anwendungen aber bei Games ist eine abgeschwächte Form von Vorteil.
Wenn der Client eine Änderung macht und dann den Server fragt, ob es korrekt war, dann hat man zwar eine sicheres Game aber der Teufel steckt im Detail.
Diese Variante kostet mehr Latenz als in einigen Spielearten gut ist.
Die Logik und Physik läuft auf beiden Systemen und der Client sendet Informationen über welche Aktion er ausführen will.
Der Client führt nun die Aktionen aus und beschleunigt nun vorwärts oder feuert ein Item ab.
Der Server prüft führt die Aktionen aus und die Aktionen selber prüfen dann, ob es möglich ist, dass man schon wieder schiessen kann oder auf eine Mauer auf gefahren ist. Der Server gibt in einem Intervall bzw. Event basiert dann den aktuellen stand zurück.
Diese Messages sollte man möglichst in UDP implementieren und auf reliable und ordered verzichten.

Paketgröße
Die Pakete sollten nicht größer als 500Byte sein und des so kleiner des so besser.
Benutze am besten 1Byte Alignment und eventuell ist auch http://visual-computing.intel-research.net/publications/mlaa.pdf dies einsetzbar.
Das Paket sollte möglichst schnell zusammen gesetzt werden können, also so wenig wie möglich Operationen benötigen und auch über Serialisierung wieder ausgelesen werden können.
Vermeide dynamische Daten, also String, Listen und ähnliches.
Sollte es mal wirklich notwendig sein, dann lege die maximalgröße fest und pack eine Längeninformation mit rein.
Ein Beispiel, im Spiel können bis zu 16 Spieler sein und die aktuellen spacial informationen sollen übertragen werden.
Dann kannst du einfach für 16 Spieler das Datenpaket erstellen, schreibst die aktuelle Anzahl an Spielern am Anfang und schreib die verfügbaren spielerinformationen, die restlichen slots bleiben unangetastet. Auf der gegenseite wird dann nur noch ein Pointer typecast gemacht von z.B. char* auf UpdateToClient* und so kann man ohne was zu konvertieren oder schrittweise zu lesen auf die Daten zugreifen.

Probleme bei Netwerk
Zu über 50% haben wir in der Firma Probleme mit Threads und Sockets, sobald die sache sauber läuft hat man recht selten Probleme.
Ein Beispiel aus der Praxis, wir Updaten mit einem Thread die Clients auf den aktuellen stand und ein Socket wird geschlossen.
Der Thread merkt dies nicht, da er in der Loop bereits ist und versucht an einen toten socket zu senden.
Es ist also notwendig zu Prüfen, ob der Socket noch verbunden ist, bevor gesendet wird oder einfach senden und die Fehlermeldung ab zu fangen.
Solche Probleme treten nur sporadisch auf, da mehrere Threads im Spiel sind und sind somit schwer zu debuggen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004