Недавно я принимал участие в разработке игры, в которой более или менее использовался тот же подход обмена сообщениями. То есть наличие удаленного сервера, который прослушивает порт где-то, а затем подключается к нему несколько клиентов и передает сообщения туда и обратно.
Это было сделано в Python, и, поскольку мы не хотели полагаться на какие-либо внешние библиотеки, мы действительно писали свои собственные акторы и систему удаленных сообщений поверх них.
Как оказалось, было несколько проблем со скоростью, но я думаю, что они были в основном связаны с тем, как Python работает с потоками (и с нашим отсутствием понимания). Тесты для Scala Actors или Akka всегда давали лучшие результаты, чем то, что мы могли сделать в Python.
Синхронизация не была для нас большой проблемой, по крайней мере, в самой игре. Но тогда у нас было не так много данных для обмена, и это была круглая игра. Таким образом, каждый из клиентов запрашивался один за другим, и в случае тайм-аута запрашивался следующий клиент. В нашей задаче клиенты реагировали только на то, что сервер представил им. Это, однако, может быть не лучшим решением в игре в реальном времени.
В режиме реального времени у вас может быть входящая очередь (Actor) на сервере для приема всех ходов клиента и, возможно, отдельный канал для состояния игры, чтобы избежать блокировки. Это действительно было бы немного сложнее для синхронизации. Так что это зависит от того, насколько быстро вам нужны обновления.