TCP服务器的要求：
目前我一直在使用C＃异步方法，但我发现在大约20个连接处总是遇到延迟。通过滞后我的意思是花费大约15-20秒来获得结果。在大约5-10个连接处，获得结果的时间几乎是立即的 实际上，当tcp服务器收到消息时，它将与一个dll进行交互，后者会进行一些处理以返回结果。不完全确定它背后的工作流程是什么，但是在小规模上你没有看到任何问题，所以我认为问题可能出在我的TCP服务器上。
现在，我想使用同步方法。这样做，我将有一个while循环来阻止accept方法，并在accept之后为每个客户端生成一个新线程。但在100个连接，它绝对是矫枉过正。
IOCP的机会，不完全确定，但它似乎就像一个连接池，因为它处理tcp的方式与正常方式非常相似。
对于这些TCP方法，我也不确定每次需要传递消息时是否更好的选择是打开和关闭连接。平均而言，消息以大约5-10分钟的间隔从每个客户端传递。
另一种选择可能是使用Web（查看通用处理程序）以仅与服务器形成1个连接。任何需要处理的消息都将传递给此通用处理程序，然后处理程序从服务器发送和接收消息。
需要特别是那些大规模执行TCP的人的建议。我没有100台PC供我测试，所以对我来说很难。语言方面的C＃或C ++会做，我对C＃更熟悉，但会考虑移植到C ++以获得速度。
答案 0 :(得分：4)
你一定做错了。我个人编写了基于C＃的服务器，可以处理1000多个连接，每秒发送超过1条消息，响应时间小于10毫秒。
如果您的响应时间很长，则必须是导致阻塞的服务器进程。也许是对锁的争论，也许是普通的坏代码，可能阻塞外部访问导致线程池耗尽。不幸的是，有很多方法可以解决这个问题，只有几种方法可以解决这个问题。有一些很好的指导方针，从Rick Vicik的High Performance Windows Programming文章中的基础知识开始，翻阅SocketAsyncEventArgs示例，其中介绍了自{{{}}出现以来在.Net中编写套接字应用程序的最佳方式。 3}}依旧等等。
如果你发现自己迷失在前面的任务中（因为它似乎恰好是你），我会敦促你接受一个既定的通信框架，也许Socket Performance Enhancements in Version 3.5使用网络绑定，然后使用{{3} }。这样你就可以依靠WCF的性能。虽然这对某些人来说可能还不够，但就性能而言，它会让你远远超过你现在肯定的程度。
答案 1 :(得分：0)
在这种情况下，我不明白为什么C＃应该比C ++更差 - 很可能你还没有找到处理传入连接的“正确方法”。为每个客户端产生一个单独的线程肯定会朝着正确的方向迈出一步，假设每个线程的工作负载比CPU密集型更多地受I / O限制。无论是通过每个连接产生一个线程还是使用线程池来管理多个线程，都是另一回事 - 通过实验来确定，同时考虑100个客户端是否是您的最大值！