在 .Net 中进行 RPC 的优化方式

Question

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

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

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

但因为我们要讨论数百个 API 命令，所以工作量很大。

对实现它的最佳方法有什么想法吗？

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

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

Answer 1

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

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

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