[IDVsbruck]

Может, мое решение достаточно узкоспециализированное, но оно имеет место в разработке нашего игрового портала. В частности, мультиплеерная игра в карты, причем игра может вестись за несколькими столами и даже на нескольких местах одного стола одним человеком (блекджек). Естественно, я говорю про игру, ведующуюся не в скачиваемом клиенте, а исключительно в HTTP-клиенте (зашел на игровой сайт, зарегился и играешь).

Я не пошел по пути создания соединения с сервером через сокеты, а выбрал периодические запросы к серверу (классический подход). Правда, на этом вся классика и заканчивается. Сервер у меня Apache Server - Apache Tomcat (платформа J2EE) и я использую технологию Continuations (Jetty + Comet), которая задерживает возвращение запроса клиенту и возвращает только при инициирования события (может, не до конца верно, но зато достаточно примитивное объяснение). К примеру, клиент выполнил действие, запрос ушел, обработался на сервере, вернулся (событие было), через доли секунды снова ушел на сервер, но теперь события нет и запрос не возвращается. Его может синициировать как действие самого клиента, так и любого другого игрока. Причем, при игре за разными столами может быть разграничение принадлежности столу и разноуровневые события - одни влияют только на обновления клиента игроков стола, а другие - глобальные - всех, играющих в данную игру.

Хотя Jetty+Comet ориентирована под Java, но для многих других языков и платформ есть аналоги. Судя по тому, что наибольшее количество инфы по ней на IBM-ских сайтах, похоже, что они "курируют" данную технологию. Там я встречал аналоги под PHP (Perl), C++.

Недостаток классического способа периодической отправки запросов в том, что надо делать паузу, иначе большое количество игроков могут повесить сервер, а пауза - это уже не полный реалтайм. Continations же позволяют выполняться запросам мгновенно, не надо инициировать паузу: ответ вернулся с сервера и тут же сформирован новый запрос, а вот сервер уже решает когда отсылать ответ (реакция на события).