Yul*_*ale 1 session websocket node.js express socket.io
我偶然发现了这篇文章。它谈到
强制每个用户使用单个 Web 套接字连接
它指出，它的一些优点是它使服务器端逻辑不那么复杂。我的问题是
- - - - - -编辑 - - - - - - -
这个问题确实没有通用的答案。只有在您的特定应用程序、其功能、设计目标、允许多个连接的具体后果（积极和消极）、其规模目标（涉及集群）、允许或存在哪些 UI 复杂性方面才能找到答案。不允许多个连接，允许或禁止多个连接会带来哪些服务器端复杂性，等等......
这里没有通用的答案。
强制每个用户使用单个 Web 套接字连接
首先，本文描述了一个特定的应用程序（游戏），该应用程序具有特定的设计目标，旨在防止用户一次通过多个页面访问服务器，因为玩家这样做可能会创造不公平的优势。这是强制每个用户使用单个 webSocket 连接的正当理由。该文章中没有任何地方表明这样做是出于任何其他原因。
强制每个用户使用单一 Web 套接字连接有什么缺点吗？
这实际上取决于您的应用程序、服务器实现和设计目标。将用户限制为一个可用的 webSocket 意味着他们一次只能打开一个活动选项卡、窗口或设备。对于一些应用程序来说，这是一个期望的事情。对于其他人来说，它只是过度限制用户，对应用程序或用户没有任何好处。
当您实现此限制时，您必须弄清楚在各种情况下您将做什么，以及如何确保用户仍然拥有适当（且良好）的用户体验。例如，假设我在桌面上打开了一个浏览器窗口（没有关闭它），我走出前门并想在手机上打开同一网站。如果手机的网络浏览器被拒绝访问该网站或被拒绝正常的功能，因为已经在另一台计算机上为该用户打开了 webSocket，那么这会导致用户突然无法使用该应用程序而感到沮丧。还有许多其他类似的边缘情况，都必须仔细考虑并适当设计。
因此，我认为在大多数情况下，如果您只是让用户打开的每个窗口都有自己的 webSocket，那么它会产生更少的用户体验边缘情况。您可以让应用程序在不活动后超时，以便最终清理不活动的套接字，并确保在用户将来返回该页面时，非活动页面中有清晰的用户界面。
因此，为每个用户强制使用单个 webSocket 连接的一个明显缺点是，您有很多用例来思考它到底如何为用户工作，并且用户是否始终清楚发生了什么以及他们是否始终可以按照自己的意愿行事，特别是在更改设备或意外打开应用程序的第二个窗口。
它使服务器端逻辑变得不那么复杂
嗯，这实际上取决于应用程序的设计。如果 webSocket 只是与它自己的网页交互，那么允许每个网页拥有自己的 webSocket 根本就没有额外的复杂性。另一方面，如果 webSocket 的目的是让该用户的所有打开屏幕都保持最新的相同信息，那么您的服务器不仅需要将发往某个特定用户的信息发送到一个 webSocket，但针对该用户的每个 webSocket。由于大多数应用程序已经具有某种机制来查找属于给定用户的 webSocket，这意味着它不是只向一个 webSocket 发送消息，而是发送到属于该用户的所有 webSocket。这种逻辑通常可以隐藏在每个人都可以调用的函数后面。在socket.io（webSockets 之上的一层）中，可以使用 rooms 概念来跟踪属于给定用户的所有套接字。
使用 websocket 创建实时应用程序时这样做是常见/良好的做法吗？
这并不是我使用具有服务器推送方面的应用程序（例如 stackoverflow）的经验，尽管应用程序是否使用 webSocket 或其他机制来获取 UI 更新并不总是很明显。如果您尝试在服务器上打开第二个窗口，您多久会收到某种类型或错误或消息？这种情况很少发生在我身上。
如果socket.io 和express 共享会话，那么强制每个用户使用单个Web Socket 连接是否有任何需要/优点？
不，没有必要强制执行。通过任何类型的用户登录，您可以轻松地在属于该用户的所有连接之间共享用户会话（如果这是您的设计目标）。请记住，您是否始终希望同一用户的所有连接使用相同的会话，这是特定于应用程序的。这实际上取决于应用程序的需求以及您在会话中执行的操作。
或者允许用户拥有多个套接字连接是否可以，只要它们都链接到其 user._id 或标识它们的其他内容？
同样，这是特定于应用程序的。在大多数情况下，我知道这很好，并且将用户限制为只有一个选项卡/窗口将被许多用户视为不必要的设计限制。
| 归档时间： |
|
| 查看次数： |
1814 次 |
| 最近记录： |