Играйте в фреймворк longpolling в онлайн игре

Question

Я работаю над браузерной игрой с игровым фреймворком, и мне определенно нужен длинный опрос, но я не совсем понимаю, как его использовать. WebSockets идеально подходит для этого, но пока еще не поддерживается многими браузерами.

Вот что я хочу сделать: когда пользователь входит в систему и переходит к игровому игровому контроллеру, я хочу установить соединение и оставить его открытым. Я хочу сделать это для всех пользователей, которые находятся в сети, чтобы я мог показать их список на сайте, чтобы они могли играть друг с другом. Я посмотрел документацию , но я не понимаю, как я мог бы реализовать это в моем случае. Поскольку я просто не хочу ничего вычислять (в примере они генерируют PDF), я просто хочу, чтобы соединение оставалось открытым.

Мне также интересно, как мне отслеживать все эти открытые соединения? Прямо сейчас у меня просто есть столбец online в моей таблице пользователей в базе данных, которую я обновляю. ТАК каждый раз, когда кто-то подключается, я должен обновить базу данных. Есть ли лучшие способы сделать это, или это нормально?

И, наконец, при условии, что все вышеперечисленное работает. Когда игрок A выбирает игрока B для игры: как мне уведомить об этом игрока B? Должен ли я просто отправить код JSON и изменить страницу с помощью javascript на стороне игрока B, или я отправлю его на совершенно другую страницу? Я не уверен, как общаться, когда два соединения установлены, и игра началась.

Answer 1

Во-первых, я думаю, вам нужно оценить разницу между Websockets и Long Polling.

Websockets создает соединение и сохраняет его открытым до тех пор, пока браузер не завершит сеанс с помощью некоторого JavaScript или перехода пользователя изстр.Это даст вам желаемую природу того, что вы запрашиваете.Изучив пример чата в загрузке Play, вы увидите, как обрабатывается все приложение чата с помощью веб-сокетов.В дополнение к ответу Пере о безгражданстве Плей.Создатели Play предположили, что одно соединение Websocket, независимо от того, как долго оно открыто и сколько запросов отправляется назад и далее, считается одной транзакцией.Следовательно, сохранение в базе данных между каждым запросом Websocket не требуется (опять же, вы можете видеть, что в примере чата ничего не сохраняется).Используя этот метод, можно ожидать, что вы сохраните детали, когда Websocket будет окончательно закрыт, или все Websockets, в зависимости от вашего варианта использования.

Длинный опрос, с другой стороны, открывает соединение с сервером,и сервер просто ждет, пока что-то будет отправлено обратно клиенту.Если вам нужно отправить какие-либо данные на сервер, вы бы сделали это как отдельный AJAX-запрос, чтобы вы могли эффективно открыть два запроса одновременно.Вы не обязательно знаете, когда пользователь выходит из системы, если только вы не отправите запрос, когда он покидает страницу, чтобы сервер знал, что он ушел, но это не всегда успешно.Длинный опрос может работать, но это не такое удобное решение, как Websockets, но, как вы говорите, это пока не получило широкого распространения.

Я бы предложил изучить пример чата (так как он имеет длинный опроси версия Websockets).Это будет наиболее эффективный способ начать работу с вашими требованиями.

Что касается вашего окончательного запроса о том, как уведомить другого игрока.В Long Polling вы просто отвечали бы на приостановленный запрос с помощью некоторого JSON.С помощью веб-сокетов вы отправляете событие обратно клиенту.Опять же, оба подхода могут быть довольно четко определены на примере чата.

Я также написал сообщение в блоге на веб-сокетах, которое может помочь вам немного лучше понять этот процесс.

Answer 2

В части Websocket, как вы можете видеть здесь (1-й ответ), поддержка не так уж плоха, и у вас есть запасной вариант Javascript, если есть какая-то проблема с браузером. Это упростит ваш сценарий, так как длительный опрос может быть более сложным для управления.

Что касается отслеживания, так как Play не имеет состояния, вы должны сохранить флаг в базе данных и удалить его при закрытии соединения. В противном случае вы нарушаете безгражданство.

Что касается уведомления, вы должны отправить какое-то сообщение B, но не перемещайте его на другую страницу, так как это может привести к путанице и ухудшить восприятие пользователем. Используйте Json, чтобы выдать какое-то сообщение (в виде div), предупреждающее их о начале игры или запросе на игру.

Answer 3

Возможно, вы захотите взглянуть на проект Juggernaut , который основан на node.js и Redis и дает вам «соединение в реальном времени между вашими серверами и клиентскими браузерами».При использовании клиента Java Redis, такого как Jedis , вы легко сможете интегрировать все это с платформой Play!

Answer 4

Я не использую фреймворк "play".

Но в последнее время я занимаюсь поиском и обработкой длинных опросов на основе http.Веб-сокеты, если таковые имеются, больше подходят для сообщений в реальном времени!

Что касается длинных опросов, я обнаружил, что использование аналогии с "грузовым автомобилем" помогло мне достаточно эффективно рассуждать о длинных опросах.Вот небольшая заметка, которую я написал по этому вопросу:

http://dvb.omino.com/blog/2011/http-comet-realtime-messages/

Возможно, вам или будущим гринперам это будет полезно.