If you're in trouble and cannot find an answer to a question which goes beyond Stack Overflow...
If you have a not-so-usual solution for your problems but need to justify it to your boss...
If you like to think on your own rather than blindly follow "common wisdom" and "profound truth"...
...then 'No Bugs' Hare on Soft.ware might be the right place for you.
Your mileage may vary. Batteries not included

Assorted Rants Tagged ‘multiplayer’, page 2:

War on Clones, Part I. IP-based (non-)Identification. Identifying PCs and Macs

Quote: “NEVER EVER use IPv4 for long-term bans”
Another Quote: “If using MAC addresses to identify devices, you SHOULD gather stats on repeating MAC addresses within your DB”
[]

Random Number Generation

Quote: “even if your RNG is statistically perfect, people will still complain 🙁 “
Another Quote: “On modern x86 CPUs, single core can generate 150M+ random bytes/second this way (and this is a Damn Lot).”
[]

Implementing Queues for Event-Driven Programs

Quote: “full queues SHOULD NOT happen during normal operation”
Another Quote: “With queues-implemented-over-mutexes like the ones we’ve written above, the most annoying thing performance-wise is that there is a chance that the OS’s scheduler can force the preemptive context switch right when the thread-being-preempted-is-owning-our-mutex.”
[]

C++ for Games: Performance. Allocations and Data Locality

Abstract: “Allocations and related lack of spatial locality can be DAMN EXPENSIVE”
Quote: “During the times of Ancient Gamers (also known as times of Atari, ZX Spectrum, and Commodore64), CPUs were running at clock speed of a single-MHz (and one operation usually took several clocks). At the same time, memory run at about the speed comparable to that of CPUs.”
[]

Marshalling and Encodings

Quote: “Encoded data size is especially important for Client-Server communications, and less important (within reason) for Server-to-Server ones and for locally-stored format.”
Another Quote: “On the other hand, due to being optimized for CPU operation, Flatbuffers are NOT optimized space-wise; even compared to not-so-optimal-space-wise Google Protocol Buffers, Flatbuffers can lose additional 1.5x in size”
[]

Network Programming: Socket Peculiarities, Threads, and Testing

Quote: “I am not saying that this architecture is the only viable one, but it does work for TCP for sure (and performs reasonably well too)”
Another Quote: “The whole task of optimizing performance beyond, say, 20-50K packets/second per box tends to be Quite Elaborated, and involves quite a few things which are platform- and hardware-dependent.”
[]