我正在开发某种在线客户端-服务器游戏。我的脑海中闪过以下想法：
在授权请求（登录名和密码）之后，客户端会收到其唯一的令牌，服务器可以通过该令牌根据来自客户端的请求识别它，直到其会话关闭。
为什么是令牌？我要求在每次请求后可以（甚至会）关闭套接字。也就是说，通过打开的套接字识别客户端对我来说不是一个选项。
但！游戏而已。所有非视觉效果都将在服务器上进行，所有视觉效果都将在客户端上进行。也就是说，所有的游戏事件都会发生在服务器上，客户端必须及时显示出来。我假设同时会有十几个客户端，每个客户端都会发送许多自己的请求。所以我需要把游戏的事件转给他们！如果服务器只知道一个关于它的令牌，它自己如何与客户端建立连接？这就是我陷入沉思的地方。
我想到的只是添加来自客户端的垃圾邮件请求，作为响应，服务器应通知他已发生的事件。我认为这不是最合理的解决方案。还有其他方法吗？
亲爱的 Shamus Rezol，恭喜你，你加入了“俱乐部”！
关于将事件从服务器传输到客户端的问题 - 自然会随着客户端和服务器之间交互场景的逐渐复杂化而出现。你问这个问题真是太好了。
让我们考虑两种情况。第一个是“浏览器游戏”
当所有客户端必须不断地“监听”来自服务器的事件时，客户端和服务器之间最简单的通信方式是 WebSocket。
WebSocket 是一种基于 TCP 连接的通信协议，旨在在浏览器和 Web 服务器之间实时交换消息。
也就是说，你的解决方案的架构变成了这样：授权后，客户端打开一个到服务器的 WS 连接并等待。
随着游戏世界在服务器上的发展，服务器向客户端发送“补丁”。客户将它们“强加”在他的卡上。当然，这些步骤中的每一个都需要详细研究，但总的来说，这就是图片。
玩家的动作从客户端传输到服务器。在同一个网络套接字上。
第二种情况是当我们没有绑定到浏览器时。
在这种情况下，事情会稍微复杂一些。
您希望从服务器接收状态更新而不保持与它的持续连接。从理论上讲，您可以使用 UDP - 只需发送带有状态更新的 UDP 数据包。那么你只有一个问题：客户端可能会“掉线”：更改 IP（客户端进入公寓并从蜂窝网络切换到家庭 WiFi）、位于不允许 UDP 的防火墙后面等。
然后你必须“围栏花园”：服务器必须“无论如何”发送数据包，即使没有任何改变，超时（例如，5秒），客户端，如果它在期间没有收到数据包超时（例如10秒），必须再次敲击服务器。
事实证明已经更加困难并且不会节省流量。也许具有永久连接的电路仍然会更简单
好吧，理论上服务器可以记住客户端的IP地址，并将其作为客户端连接到服务器。但是在当前的 Internet 中，这种方法无法与 NAT 和其他防火墙和防火墙一起使用。
因此，只剩下一个正常的选择——服务器只需要等到客户端加入它并确认它的令牌。