I have a theory here, believing this might be a problem of just using one ProtocolProcessor for all WebSocketSessions:
When sending binary data, the DraftHybi10Processor would call "EnqueueSend", passing in the current WebSocketSession and the data to be sent.
That method appends the passed in data to the end of a Queue, and then calls "DequeueSend", passing on the WebSocketSession.
DequeueSend checks, whether the ProcotolProcessor is already sending data from the queue.
If not, it starts calling SocketSession.SendResponse() on the WebSocketSession, until either the something turns wrong with the connection, or the queue is emptied.
The check for an empty queue and the actual dequeue are protected by a lock, that is shared by the call to Enqueue() within EnqueueSend().
Imagine now a scenario, where one thread adds a message for WebSocketSession "A" to the then empty queue, and starts the dequeue-send loop within DequeueSend.
Someanother thread calls EnqueueSend for a different WebSocketSession "B", while DequeueSend is still inside the loop.
If the loop is currently checking the queue or dequeuing an item, the lock will ensure the Enqueue will not interfere.
There is though a slight possibility, that thread 2 will actually get to Enqueue its data after thread 1 called dequeue and exited the lock and before thread 1 reenters the lock and checks the queuelength again.
In that case, DequeueSend shall eventually dequeue the data enqueued by thread 2, and send it to the WebSocketSession it was originally passed (i.e. "A"), and not "B", as would have been the intention.