4

我正在用 Java 编写基于服务器-客户端架构的游戏。

出于设计原因，我想使用异步调用将客户端操作传递给服务器，并使用异步回调将所述操作的结果传递回客户端。异步调用允许缓冲客户端操作。排队缓冲允许对客户端操作进行简单的、基本上是一个线程的处理。

目前，我的服务器和客户端代码非常对称。他们创建一个注册表，然后导出并绑定自己。

异步性是通过在 ConcurrentLinkedQueue 中缓冲传入的操作或结果来实现的。实际处理由定期运行的线程完成。

但是，当客户端有防火墙或在 NAT 后面时，此当前架构不起作用。在这种情况下，服务器根本无法联系到客户端将结果推送给他们。

此外，在当前的架构中，服务器不知道哪个客户端发送了给定的操作，除非引入了冗余的身份验证或会话处理层。这允许伪造行为和作弊。

我一直在考虑可能的解决方案，但没有找到合适的解决方案：

  • 客户端拉取而不是服务器推送。服务器上可能存在客户端定期调用以获取其结果的方法。然而，这种方法看起来很丑陋，它引入了额外的延迟、带宽和时序问题。也不解决伪造行为。直接通知也非常受欢迎。

  • TCP 连接本身允许双向通信，并且肯定可以识别客户端，因此 RMI 或 JRemoting可能会被黑客入侵以支持它，但我不知道如何，而且我不知道任何现有的解决方案。

  • 消息传递。我不确定消息传递框架是否支持身份验证/会话或客户端识别。不过，我肯定会失去远程方法。

  • 我相信正确的解决方案是找到一个支持以上所有内容的远程方法调用框架。

所以简而言之，我正在寻找一种方法：

  • 异步调用服务器或将消息传递给它
  • 异步调用客户端或将消息传递给它，即使在防火墙或 NAT 之后
  • 识别发送动作的客户端
  • 最好能够调用方法，而不仅仅是传递消息
  • 保持使用 JUnit 和 Mockito 轻松测试它的能力（每台机器有多个客户端）

是否有任何支持这些的远程方法调用框架？哪个是最好的？

4

1 回答 1

5

我不知道您为什么要坚持使用 RMI 或类似的东西，因为根据定义它是单向的。但是我必须学习类似的教训……对于我的一个客户端-服务器系统，我使用 RMI 和长轮询实现了与您现在所拥有的类似的东西。结果证明这是一个可怕的混乱，而且越来越糟。

然后我发现了发布-订阅框架的美妙世界。这些是构建客户端-服务器应用程序的自然方式，无需实现大量自己的管道。此外，这些框架支持自动保活、时间同步、会话身份验证和权限，以及您不想自己实现的大量其他内容。

对于我的项目，我删除了我自己的所有工作并用CometD替换它，它支持 Java 和浏览器 (Javascript) 客户端，并且非常高兴。它肯定会支持您的所有需求——从任何一方发起的异步通信、客户端识别（和许多其他功能）以及 NAT 后面的客户端一旦建立连接就不会成为问题。编写测试也很容易，并且整个框架已经扩大到能够处理 10 万个客户端，这对于 RMI 来说是不可能的。

我强烈建议您考虑放弃能够远程调用方法的要求。方法本质上是片面的，但它们仍然需要调用和返回。使用事件驱动编程来设计系统要好得多。

更新：我已经转向网络应用程序的世界，特别是使用Meteor。

于 2013-02-24T05:38:35.177 回答