c# - 超高性能套接字服务器 - 实现细节

Question

我做过研究，我知道实现高性能套接字服务器的最佳方法通常如下:使用异步套接字操作(专门的 SocketAsyncEventArgs/Operations 以获得最佳性能)和异步回调，将请求推送到由线程池管理的处理队列。

我对这个处理模型的问题 - 获得最好的性能:

1) 什么时候应该调用套接字的“结束”操作(例如 EndAccept 或 EndReceive)？这应该在排队请求之前在回调线程(IOCP)上调用吗？或者当请求从队列中取出并被处理时调用(工作线程)？

2) 这个问题取决于#1 的答案。什么时候应该调用下一个“开始”操作？我们应该在调用 EndOperation 之前调用它，还是应该在 EndOperation 之后立即调用它(在排队/处理请求之前)？

3) 处理队列可以只是 .NET 线程池吗？与推出您自己的同步处理队列相比，使用 .NET 线程池有哪些优点/缺点？

非常感谢任何帮助。

Answer 1

1) EndReceive 应该是您在异步回调中做的第一件事。事实上，在调用 EndReceive 之前，您不能在回调中做任何其他事情，因为这就是为您提供接收到的数据的原因。请参阅 Socket.EndReceive 处的示例.

EndAccept 同样如此，因为它为您提供了您将与之通信的套接字。

2) 您应该在 EndAccept 之后尽快调用 BeginAccept。否则，如果您的接受回调处理时间过长，您可能会丢失连接请求。当然，如果您的接受回调需要很长时间才能执行任何操作，那么您就做错了。同样，BeginReceive 也是如此:在 EndRead 之后尽快调用它，以避免丢失数据。或者，如果您的通信协议(protocol)是请求/响应模型，客户端希望在发送任何更多数据之前得到响应，您可以等到发送响应后再调用 BeginRead。

3) 处理可能是 .NET 线程池，但如果您要使用它，您应该考虑使用 Task Parallel Library。使用 TPL 的优势在于它非常“发射后不管”，或者可能是“发射后它会在完成时回调”。使用 TPL 的缺点是您的应用程序更难知道哪些任务未决。如果您创建自己的同步处理队列，您总是知道哪些作业正在等待处理，并且您有可能检查队列、取消作业等。如果您想使用 TPL 执行此操作，您最终会创建一个任务集合你必须管理，因为有 no way to get the the list of pending tasks .

但如果您不需要查看挂起的任务，那么 TPL 应该可以正常工作。

这里的相关问题有一些很好的信息。