Там действительно нет общего ответа на этот вопрос. Есть только ответы в контексте вашего конкретного приложения, его функций, целей проектирования, конкретных последствий (как положительных, так и отрицательных) для разрешения нескольких соединений, целей масштабирования (включает кластеризацию), какие сложности пользовательского интерфейса имеют, допуская илизапрещение множественных подключений, какие сложности на стороне сервера возникают из-за разрешения или запрещения нескольких подключений и т. д. на пользователя
Во-первых, в этой статье описывается конкретное приложение (игра), которое имеет особую цель разработки, чтобы предотвратить доступ пользователя к серверу через более чем одну страницу за раз, потому что игрок могвозможно создать несправедливое преимущество в этом. Это веская причина для принудительного применения одного соединения webSocket для каждого пользователя. Нигде в этой статье не указывается, что это делается по любой другой причине, кроме этой.
Есть ли какой-либо недостаток в принудительном использовании подключения к одному веб-сокету для пользователя?
Это действительно зависит от вашего приложения, реализации вашего сервера и ваших целей проектирования. Ограничение пользователя одним функционирующим webSocket означает, что у него может быть только одна активная вкладка, окно или устройство, открытое одновременно. Для некоторых приложений это желаемая вещь. Для других это просто ограничивает пользователя без какой-либо выгоды для приложения или пользователя.
Когда вы реализуете это ограничение, вы должны выяснить, что вы собираетесь делать, для целого ряда обстоятельств и какВы убедитесь, что пользователь все еще имеет соответствующий (и хороший) пользовательский опыт. Например, предположим, что у меня на рабочем столе открыто окно браузера и (не закрывая его) я выхожу через переднюю дверь и хочу открыть тот же сайт на моем телефоне. Если веб-браузеру телефона отказано в доступе к сайту или отказано в надлежащей функциональности, поскольку для этого пользователя на другом компьютере уже открыт webSocket, то это приводит к разочарованию пользователя, который внезапно не может использовать приложение. Существует множество других крайних случаев, таких как этот, которые все должны быть тщательно продуманы и спроектированы надлежащим образом.
Итак, я бы сказал, что в большинстве случаев это создает гораздо меньше случаев пользовательского опыта, если вы просто позволитеКаждое окно, которое открывает пользователь, имеет свой собственный webSocket. Вы можете настроить время ожидания приложения после неактивности, чтобы в конечном итоге очистить неактивные сокеты и убедиться, что на неактивной странице имеется понятный пользовательский интерфейс, если пользователь вернется на эту страницу в будущем.
Таким образом, явным недостатком принудительного использования одного подключения webSocket для пользователя является то, что у вас есть много вариантов использования, чтобы продумать, как именно это работает для пользователя, и всегда ли пользователь ясно понимает, что происходит, и может ли он всегда делать то, что он намерен, особенно когдасмена устройств или случайное открытие второго окна для приложения.
это делает логику на стороне сервера менее сложной среди других
Что ж, это действительно зависит от дизайна приложения. Если webSocket просто взаимодействует со своей собственной веб-страницей, то разрешение каждой веб-странице иметь свой собственный webSocket вовсе не является дополнительной сложностью. Если, с другой стороны, цель webSocket состоит в том, чтобы поддерживать все открытые экраны для этого пользователя в актуальном состоянии с одной и той же информацией, то вашему серверу нужно не просто отправлять информацию, предназначенную для одного конкретного пользователя, только в один webSocket,но каждому webSocket для этого пользователя. Поскольку большинство приложений уже имеют какой-то механизм поиска веб-сокета, принадлежащего данному пользователю, это означает, что вместо отправки сообщения только одному веб-сокету, он отправляет все веб-сокеты, принадлежащие этому пользователю. Эту логику обычно можно просто спрятать за функцией, которую может вызвать каждый. В socket.io (слой поверх webSockets) можно использовать концепцию комнат для отслеживания всех сокетов, принадлежащих данному пользователю.
Является ли это обычной / хорошей практикой делать это при создании приложений реального времени с использованием веб-сокетов?
У меня не было опыта использования приложений, которые имеют некоторый аспект серверной пересылки дляих (например, stackoverflow, хотя), хотя не всегда очевидно, использует ли приложение webSocket или какой-либо другой механизм для получения обновлений пользовательского интерфейса. Как часто вы получаете какой-либо тип или ошибку или сообщение, если вы пытаетесь открыть второе окно на сервере? Это редко случается со мной.
Есть ли необходимость / преимущество принудительного подключения к одному веб-сокету для пользователя, если socket.io и express совместно используют сеансы?
НетНет необходимости применять его. При любом входе пользователя в систему вы можете легко обмениваться пользовательскими сеансами между всеми подключениями, принадлежащими этому пользователю, если это ваша цель разработки. Имейте в виду, что это зависит от приложения, хотите ли вы, чтобы один и тот же сеанс всегда выполнялся для всех подключений одним и тем же пользователем. Это действительно зависит от потребностей приложения и от того, что вы делаете с сеансом.
Или можно разрешить пользователю иметь несколько соединений с сокетами, если они все связаны со своим пользователем._id или что-то, что их идентифицирует?
Опять же, это зависит от приложения. В большинстве случаев я знаю, что это нормально, и ограничение пользователя только одной вкладкой / окном будет восприниматься многими пользователями как ненужное ограничение дизайна.