不过 HTTP（前面已经提到服务器为REST API）不允许这种类型的行为。所以，我们的选择是：
- 每隔 X 秒从客户端轮询，
- 使用某种与客户端-服务器连接通信机制并行工作的通知系统。
根据我的经验，我倾向于选择选项 2。实际上，我会（在本文中）使用Redis来实现这种行为。
下图演示了服务之间的依赖关系。
客户端应用程序与游戏引擎之间的交互
聊天服务器
我将把这个模块的设计细节留给开发阶段（本文不涉及这一部分）。话虽如此，我们仍可以决定一些事情。
我们可以确定的一件事是服务器的限制集合，这将简化我们的工作。如果我们正确地玩牌，最终可能会有一个提供强大界面的服务，从而允许我们去进行扩展甚至修改实现，以提供更少的限制，而不会影响到游戏。
- 每个组队只有一个房间。
- 我们不会创建子组队。这和不让组队分裂是相辅相成的。也许一旦以后我们实现了这个增强功能，允许创建子组和自定义聊天室或许是一个好主意。
- 没有私信功能。
- 这纯粹是为了简化，但是只有群聊并不够好。目前我们不需要私信。请记住，任何时候只研究你的最小化可行产品，尽量避免掉进不必要功能的陷阱；这是一条危险的道路，很难从困境中摆脱出来。
- 不会保存留言。
- 换句话说，如果你离开组队，将会丢失这些信息。这将极大地简化我们的任务，因为我们不必处理任何类型的数据存储，也不必浪费时间来优化存储和恢复旧消息的数据结构。它们都存在于内存中，只要聊天室处于活动状态，就会一直存在。一旦关闭，就会简单地对它们说Goodbye！
- 通过网络套接字进行通信。
- 可悲的是，我们的客户将不得不处理双重沟通渠道：游戏引擎的 RESTful 和聊天服务器的套接字。这可能会增加客户端的复杂性，但与此同时，它将为每个模块使用最佳通信方法。 （在聊天服务器上强制 REST 或在游戏服务器上强制使用套接字没有任何意义。这种方法会增加服务器端代码的复杂性，这也是处理业务逻辑的代码，所以让我们关注目前的问题。）