WebSocket: отправка идентификатора пользователя с каждым сообщением

Я пишу простую многопользовательскую браузерную игру, которая использует WebSockets для отправки информации между клиентом и сервером.

Когда я изначально разрабатывал протокол, я решил, что каждый заголовок сообщения будет содержать идентификатор пользователя (случайно сгенерированный UUID). Если соединение было разорвано, клиент попытается восстановить соединение, и сервер сможет идентифицировать клиента по идентификатору пользователя.

Я использовал только протокол UDP без установления соединения для отправки данных по сети. Я понял, что WebSocket построен поверх TCP, что означает, что сокет больше похож на поток данных, а не на отдельные пакеты, которые могут достичь или не достичь своего пункта назначения.

Я начинаю сомневаться в отслеживании идентификаторов пользователей в сообщениях. Поскольку TCP по своей сути основан на соединении, нужно ли мне отслеживать идентификатор пользователя? Есть ли какие-либо преимущества в отслеживании идентификатора пользователя? Если соединение будет разорвано, сервер и клиент переподключатся автоматически? Я не очень далеко продвинулся в реализации игры. Должен ли я просто отказаться от идеи с идентификатором пользователя?


userid websocket network-protocols
person Moyamo    schedule 14.12.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Добавление уникального идентификатора в каждое сообщение кажется излишним. Ваш веб-сервер должен отслеживать соединения, пока они остаются подключенными. Но вам понадобится идентификатор пользователя, если клиент отключится, чтобы сохранить непрерывность, поэтому я бы отправил идентификатор пользователя клиенту только один раз, при первом подключении клиента. Затем клиент может отправить его обратно, если ему нужно повторно подключиться, и ваша игра может возобновиться с того места, где она остановилась.

Конечно, использование поставщика сеансов с вашим сервером веб-сокетов также позаботится об этом...

person mattexx    schedule 14.12.2013
comment
Спасибо за ответ. Не могли бы вы уточнить, что такое поставщики состояния сеанса? Быстрый поиск в Google показал, что это проблема .NET, которая является проблемой для серверов Linux. - person Moyamo; 15.12.2013
comment
Сеансы определенно не ограничиваются .NET. Какой сервер веб-сокетов вы используете? У многих эта возможность встроена. - person mattexx; 15.12.2013
comment
Я использую веб-фреймворк торнадо. В очередной раз благодарим за помощь. Я определенно сделаю больше исследований в этом вопросе. Хотя я думаю, что использование провайдеров сеансов выходит за рамки этого вопроса, и, вероятно, на него не следует отвечать в ветке комментариев SO. Я отмечу ответ как принятый. - person Moyamo; 16.12.2013

arrow_upward
0
arrow_downward

Соединения TCP являются соединениями с отслеживанием состояния — пакеты данных отправляются от источника к месту назначения, а пакеты подтверждения принимаются от места назначения источником (двунаправленным — любая сторона может быть источником или получателем) — это обрабатывается сетевым стеком и невидимый для вас.

Однако повторное подключение не происходит автоматически, и для повторного подключения потребуется вмешательство с вашей стороны (скорее всего, со стороны клиента).

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

Все это тоже теоретические догадки с моей стороны — мой вам совет — просто начните переделывать дизайн и посмотрите, что работает. :) Нет реальной необходимости пытаться спроектировать и предвидеть все идеально, даже не начав.

person Kilanash    schedule 14.12.2013