Inbound packets should be queued and processed synchronously

[tristonplummer]

While the current asynchronous networking implementation is considerably more scalable, networking in game servers should almost always be synchronous as data races can lead to potentially catastrophic consequences.

It is currently theoretically possible to both drop an item, and trade it to a player at the same time - if both packets are processed asynchronously, there is a chance that both threads will see the item, and thus the action, as valid, and proceed.

The server should instead queue up all inbound packets and process them in a FIFO fashion for each active player. The packets should then be processed at the beginning of a game tick (I think 50ms is a respectable time for this).

On a similiar note, while packets can be written to the client at any time, the channel should only be flushed once at the end of the game tick, as this is the most expensive part of the packet sending operation.

[aosyatnik]

I got your point. Although I'm not quite sure, that I want to implement this architectural change. Usually, all sensitive data(e.g. items, buffs, players) is stored in ConcurectDictionary, which is thread-safe. So several threads can not hurt them. But there might be other side-effects, that I'm not aware of right now. I'll keep this issue open and think later about what side-effects could be introduced by the async socket model. Thanks for the feedback!