实时应用程序的异步与同步套接字服务器
我目前正在开发一个 C# 套接字服务器，需要向实时进程发送和接收命令。客户端是Android设备。目前实时要求是“软”的，但将来可能会出现更严格的时序要求。假设将来可能会向起重机发送可能存在潜在危险的命令。
服务器正在工作，并且看起来非常适合我当前的同步套接字服务器设计。我有单独的线程用于接收和发送数据。我想知道是否有任何理由尝试异步服务器套接字方法？它可以提供更高的稳定性和/或更快的性能吗？
I am currently developing a C# socket server that needs to send and receive commands to a real-time process. The client is an android device. Currently the real-time requirements are "soft", however in the future more strict timing requirements might arise. Lets say in the future it might be to send commands to a crane that could be potentially dangerous.
The server is working, and seemingly very well with my current synchronous socket server design. I have separate threads for receiving and sending data. I am wondering if there would be any reason to attempt an asynchronous server socket approach? Could it provide more stability and/or faster performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我将掩盖实时的定义，并说异步套接字不会使请求处理的主体更快，但会增加并发性（您可以在任何时候接受的请求数量）。如果所有处理器都忙于处理某些内容，您将不会获得任何收益。这只会让您在处理器等待套接字接收某些内容的情况下获益。
只是关于实时的说明，如果您的实时要求类似于保证 x-time 响应的需要，那么 C# 和 .NET 不会给您这样的保证。然而，这取决于您当前和未来对“软”的定义。您可能碰巧获得了良好的响应时间，但不要将其与真正的实时系统混淆。
I'll gloss over the definition of real time and say that asynchronous sockets won't make the body of the request process any faster, but will increase concurrency (the number of requests you can take at any one time). If all processors are busy processing something, you won't get any gain. This only gives you gain in the situation where a processor would have sat waiting for a socket to receive something.
Just a note on real time, if your real time requirements are anything like the need to guarantee a response in x-time, then C# and .NET will not give you such guarantees. This, however, depends on your current and future definitions of "soft". It may be the case that you happen to be getting good response times, but don't confuse that with true real time systems.
如果您怀疑应用程序中异步功能的实用性，那么您绝对应该阅读此内容。它让您清楚地了解异步解决方案可以为您的应用程序添加哪些内容
If you're doubting the usefullness of something asynchronous in your aplications then you should definitely read about this. It gives you a clear idea of what the asynchronous solutions could add to your applications
我认为您不会获得更高的稳定性或更快的性能。如果它确实是一个“实时”系统，那么它应该是同步的。如果您可以容忍“近实时”并且存在长时间运行或昂贵的计算操作，那么您可以考虑异步方法。如果不需要的话我不会增加复杂性。
I don't think you are going to get more stability or faster performance. If it really is a "real-time" system, then it should be synchronous. If you can tolerate "near real-time" and there are long running or expensive compute operations, then you could consider an asynchronous approach. I would not add the complexity if not needed though.
如果它是实时的，那么您绝对希望您的通信由队列支持，以便您可以证明该队列上的时间逻辑。这就是 nio/io-completion-ports/async 为您提供的。如果您使用同步编程，那么在将数据从 RAM 复制到网卡时就会浪费 CPU。
此外，这意味着您的服务器绝对是单线程的。即使使用异步，您也可能只有一个线程，但仍然能够处理数千个请求。
举例来说，客户端想要执行 DOS 攻击。他将连接并发送一个字节的数据。您的应用程序现在将无法接收该连接超时的进一步命令，该超时可能非常大。使用异步，您将确认 SYN 包，但您的代码不会等待完整传输。
If it's real time, then you absolutely want your communications to be backed by a queue so that you can prove temporal logic on that queue. This is what nio/io-completion-ports/async gives you. If you are using synchronous programming then you are wasting your CPU while copying data from RAM to the network card.
Furthermore, it means that your server is absolutely single-threaded. You may have a single thread even with async, but still be able to serve thousands of requests.
Say for example that a client wanted to perform a DOS attack. He would connect and send one byte of data. Your application would now become unable to receive further commands for the timeout of that connection, which could be quite large. With async, you would ACK the SYN package back, but your code would not be waiting for the full transmission.