Leonardo Hahn

Awesome! I will give it a try.

Version 2 was already merged in the main branch: https://github.com/topfreegames/pitaya/blob/main/go.mod. The project is far from being dead, we use it extensively in production and for new games. Unfortunately, our company...

> Data received from the same player may be processed in different coroutines This should not be the case, since we process all messages on the same goroutine: https://github.com/topfreegames/pitaya/blob/177cdf3913e6bd7fa5d0f0ac01dca4c7400a3985/service/handler.go#L183 Are...

Oh, so you're talking about `clients` as other servers right? Because indeed, messages are not ordered between servers communicating. However, when I mentioned client, I was talking about the device...

Indeed, what I said before was wrong. The dispatch code also processes messages from the client. Really good find. IMO, I think having only one coroutine for processing player messages...

Another potential option would be to have a concept or "ordered packets" from the client. So we would then have two coroutines, one for multiple coroutine processing, and another channel...

This seems to be a good solution overall. I don't see many issues here apart from the potential issue of client starving that you mentioned. I assume the consuming threads...

Thinking about it in a simpler way, did you consider just guaranteeing the ordering on client-side? For example, you can wait for the response on the client (libpitaya) before sending...

Is the sync servers really necessary though? For example, pitaya itself does not use the method, so nothing would stop someone from implementing their own service discovery without it (we...

The lib is already being used in production. The API however is still quite unstable, so the documentation is still being worked on.