在.Net 中进行 RPC 的优化方法
我正在考虑将 .Net 应用程序的一部分移动到其他计算机上。执行此操作的明显方法是简单地使用带有二进制 tcp 协议的 WCF，例如“ 使用 .NET 获得快速 RPC 的最简单方法？”。
我将拨打大量电话，延迟是一个大问题。基本上，一台计算机将运行物理模拟器，其他计算机将使用包含数百个命令的 API 与其进行交互。
我认为最好的方法是制定一个自定义二进制协议，其中 API 命令由 int16 和序列号标识，后跟所需的参数。对发送和接收类进行硬连线将消除任何不必要的开销。
但这是一项繁重的工作，因为我们正在谈论数百个 API 命令。
关于实施它的最佳方法有什么想法吗？
编辑： 澄清一下：据我所知，.Net 中的序列化并未优化。在序列化和反序列化对象时存在相对较高的惩罚，例如反射的内部使用。这是我想要避免的，因此我的想法是围绕直接映射（硬连线）方法。
经过一番搜索，我发现了一个我模糊记得的应用程序： http://www.protocol-builder.com /
I'm considering to move parts of a .Net application to other computers. The obvious way to do this is simply using WCF with a binary tcp protocol, for example as describer in " Easiest way to get fast RPC with .NET? ".
I'll be making a vast amount of calls and latency is a big issue. Basically one computer will be running a physics simulator and the others will be interacting with it using a API of several hundred commands.
I'm thinking the best way is to make a custom binary protocol where API commands are identified by int16 and a sequence number, and followed by the required parameters. Hardwiring the send and receive classes would remove any unnecessary overhead.
But that is a LOT of work since we are talking several hundred API commands.
Any thoughts on the best way to do implement it?
Edit:
To clarify: AFAIK serialization in .Net is not optimized. There is a relatively high penalty in serializing and deserializing objects in for example the internal use of Reflection. This is kind of what I want to avoid, and hence my though around directly mapping (hardwiring) methods.
After some searching I found one app I had a vague recollection of: http://www.protocol-builder.com/
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
减少总流量（这将是自定义协议相对于使用 WCF 的主要好处）不会对延迟产生很大影响。主要问题是将“所需参数”的数据量保持在最低限度，因此每个请求相对较小。 WCF 中的默认序列化已经相当高效，尤其是在本地网络上使用 TCP 时。
在您描述的场景中，许多客户端连接到集中式服务器，消息传输本身不太可能成为瓶颈 - 处理特定消息可能会成为瓶颈，而传输机制不会同样重要。
就我个人而言，我只会使用 WCF，而不会尝试构建自定义协议。如果在运行后发现有问题，您可以轻松地将传输抽象为自定义协议当时，并将其映射到相同的接口。与仅预先执行自定义协议堆栈相比，这将需要很少的额外代码，并且可能使代码更加干净（因为自定义协议将被隔离为到“干净”API 的单个映射）。但是，如果您发现运输不是瓶颈，那么您将节省大量的劳动力和精力。
Reducing the total traffic (which would be the main benefit to a custom protocol vs. using WCF) is not going to have a large effect on latency. The main issue would be keeping the amount of data for the "required parameters" to a minimum, so each request is relatively small. The default serialization in WCF is fairly efficient already, especially when using TCP on a local network.
In a scenario like you're describing, with many clients connecting to a centralized server, it is unlikely that the transport of the messages itself will be the bottleneck - processing the specific messages will likely be the bottleneck, and the transport mechanism won't matter as much.
Personally, I would just use WCF, and not bother with trying to build a custom protocol. If, once you have it running, you find that you have a problem, you can easily abstract out the transport to a custom protocol at that time, and map it to the same interfaces. This will require very little extra code vs. just doing a custom protocol stack up front, and likely keep the code much cleaner (since the custom protocol will be isolated into a single mapping to the "clean" API). If, however, you find the transport is not a bottleneck, you will have saved yourself a huge amount of labor and effort.