Currently RakLib uses two global channels for inter-thread communication (one for each direction).

These global channels are a major bottleneck for RakLib scaling because every packet sent or received from any session passes through these channels. This has two effects:

• Frequent lock contention: it's likely that contention for mutex locking will occur when pushing stuff into channels while the other thread is trying to pull it out.
• Inability to use multiple CPU cores: these central channels are a big showstopper for parallel scaling, because inevitably worker threads would end up contending for locks on the channels with other worker threads.

This issue proposes that each RakLib session should have its own ITC channel pair. This may be tricky to implement due to pthreads stupidity, but in terms of code complexity it's simple and effective.

The current design restricts the use of the inter-thread messaging to just sending instructions back and forth. It's not possible for the user thread to, for example, request statistics for a particular session to be returned to the main thread, without modifications to RakLib itself.