考虑一个托管许多桌子的扑克游戏服务器。当玩家在大厅时，他有一个所有活动桌及其统计数据的列表。当玩家加入、玩和离开牌桌时，这些统计数据会不断变化。可以添加和关闭表格。不知何故，这些更改必须通知客户。
您将如何实现此功能？你会为大厅使用 TCP/UDP（也就是说，用户应该连接到服务器来观察大厅，还是你会使用请求-响应机制）？服务器会通知客户端每个事件，还是客户端轮询服务器？
请记住这一点：也许这样一个系统最重要的目标是可扩展性。添加更多服务器应该很容易以应对日益增长的用户需求，而所有用户都应该看到一个包含多个服务器的大列表。
这个特定问题是应用程序设计中一个非常基本的问题的表现——客户端应该如何连接到服务器。
当可伸缩性成为一个问题时，总是求助于可伸缩的解决方案，使用非阻塞 I/O 模式，例如Reactor 设计模式。更可取的是使用已经具有此类模式的工作和测试实现的标准解决方案。
特别是在您的情况下，它涉及一个不断更新的快速动作游戏，使用可扩展服务器（同样，非阻塞 I/O）听起来很合理，它通过 TCP 与每个客户端保持连接，并更新他他需要知道的信息。
请求-响应周期听起来不太适合您的情况，但这应该根据您的应用程序的确切规范进行验证。
这是我的基本建议：
服务器通过一个接口更新列表（添加、删除和更改现有项目），该接口保留已应用于列表的固定长度操作队列。每个操作都有一个时间戳。当队列已满时，最旧的操作将逐渐被丢弃。
当用户第一次需要检索列表时，它会要求服务器向他发送完整的列表。服务器发送带有当前时间戳的列表。
每个任意时间段（10-30 秒？）客户端要求服务器向他发送自他获得时间戳以来已应用于列表的所有操作。然后服务器检查时间戳是否仍然出现在列表中（也就是说，它大于第一项的时间戳），如果是，则向客户端发送从那时到现在发生的操作列表，加上当前时间戳。如果它太旧，服务器会再次发送完整列表。
UDP 似乎适合这种方法，因为如果偶尔丢失“更新周期”也没什么大不了的。