.net - 在 .Net 中进行 RPC 的优化方法

Question

我正在考虑将 .Net 应用程序的一部分移到其他计算机上。显而易见的方法是简单地将 WCF 与二进制 tcp 协议(protocol)一起使用，例如“Easiest way to get fast RPC with .NET?”中的描述。

我会打大量电话，延迟是一个大问题。基本上，一台计算机将运行物理模拟器，而其他计算机将使用数百个命令的 API 与之交互。

我认为最好的方法是制作一个自定义二进制协议(protocol)，其中 API 命令由 int16 和序列号标识，然后是所需的参数。硬连线发送和接收类将消除任何不必要的开销。

但这需要做很多工作，因为我们正在讨论数百个 API 命令。

关于实现它的最佳方法的任何想法？

编辑:
澄清:.Net 中的 AFAIK 序列化未优化。例如在反射的内部使用中，序列化和反序列化对象的代价相对较高。这是我想避免的，因此我的想法是直接映射(硬连线)方法。

经过一番搜索，我发现了一个我模糊记得的应用程序:http://www.protocol-builder.com/

Answer 1

减少总流量(这将是自定义协议(protocol)与使用 WCF 相比的主要好处)不会对延迟产生很大影响。主要问题是将“所需参数”的数据量保持在最低限度，因此每个请求都相对较小。 WCF 中的默认序列化已经相当有效，尤其是在本地网络上使用 TCP 时。

在您所描述的场景中，许多客户端连接到集中式服务器，消息本身的传输不太可能成为瓶颈 - 处理特定消息可能会成为瓶颈，而传输机制不会一样重要。

就个人而言，我只会使用 WCF，而不会费心尝试构建自定义协议(protocol)。如果在运行后发现有问题，则可以轻松地将传输抽象出到当时的自定义协议(protocol)，并将其映射到相同的接口(interface)。这将只需要很少的额外代码，而只是预先做一个自定义协议(protocol)堆栈，并且可能会使代码更干净(因为自定义协议(protocol)将被隔离到一个到“干净”API 的映射中)。但是，如果您发现运输不是瓶颈，您将为自己节省大量的劳力和精力。