.NET3.5中的高性能 Socket API

本文版权归 博客园 TianFang 所有，转载请自觉显式标明原创作者及出处，以示尊重！

作者：TianFang

原文：http://www.cnblogs.com/TianFang/archive/2007/11/09/954730.html

 

     在 .NET Framework 2.0 版本中，System.Net.Sockets 命名空间提供了一个几乎拥有 Windows WinSock Win32 API 的所有功能的 Socket 类。该功能所属的类包含为托管代码开发人员设计的各种方法和属性。在 Socket 上，有一组包括 Send 和 Receive 在内的同步方法，具备针对各种情况的参数重载。这些同步方法不仅易于使用，而且非常适合于使用套接字的简单网络任务。Socket 上还有一组基于异步编程模型 (APM) 的异步方法，APM 在 .NET Framework 中非常普遍（有关详细信息，请参阅 msdn.microsoft.com/msdnmag/issues/07/03/ConcurrentAffairs）。这些异步方法让 Socket 类的异步使用相对简单，而且还提供了一种方法来处理许多套接字，或处理在许多套接字上进行的多个发送和接收操作。

      2.0 版本的 Socket 类适合多种需要使用网络套接字的客户端应用程序，以及一些服务器和服务类型的应用程序。遗憾的是，一些服务应用程序方案不适用于 2.0 版本的 Socket 类，却和直接使用 Windows WinSock API 的本机语言相容。2.0 版本的 Socket 类的主要问题是它不仅在分配必要的基础对象以便在大量套接字上同时保持 I/O 操作时需要占用过多的 CPU 循环，而且在执行单个套接字 I/O 操作时也同样如此。

       凭借 .NET Framework 3.5，公共语言运行时 (CLR) 便可以更有效地同时管理大量的 Overlapped 对象。CLR 中的 Overlapped 对象可以有效封装用于管理异步 I/O 操作的本机 Windows OVERLAPPED 结构。每个进行中的 Socket 异步 I/O 操作中都有一个 Overlapped 对象实例。现在可以拥有 6 万个甚至更多的连接套接字，并同时在每个套接字上保持一个挂起的异步接收 I/O 操作。

        2.0 版本的 Socket 类使用 Windows I/O 完成端口来完成异步 I/O 操作。这使应用程序可以轻易地扩展到大量的打开的套接字。.NET Framework 实现了 System.Threading.ThreadPool 类，该类提供可读取完成端口并完成异步 I/O 操作的完成线程。在开发即将发布的 3.5 版本的 .NET Framework 的过程中，我们将大量的精力放在了消除代码路径中的开销上，包括读取完成端口和调用应用程序的完成代理或在 IAsyncResult 对象中发出 I/O 完成事件对象信号之间。

        .NET Framework 中的 APM 也称为 Begin/End 模式。这是因为会调用 Begin 方法来启动异步操作，然后返回一个 IAsyncResult 对象。可以选择将一个代理作为参数提供给 Begin 方法，异步操作完成时会调用该方法。或者，一个线程可以等待 IAsyncResult.AsyncWaitHandle。当回调被调用或发出等待信号时，就会调用 End 方法来获取异步操作的结果。这种模式很灵活，使用相对简单，在 .NET Framework 中非常常见。

        但是，您必须注意，如果进行大量异步套接字操作，是要付出代价的。针对每次操作，都必须创建一个 IAsyncResult 对象，而且该对象不能被重复使用。由于大量使用对象分配和垃圾收集，这会影响性能。为了解决这个问题，新版本提供了另一个使用套接字上执行异步 I/O 的方法模式。这种新模式并不要求为每个套接字操作分配操作上下文对象。

        我们没有创建全新的模式，而只是采用现有模式并做了一个基本更改。现在，在 Socket 类中有了一些方法，它们使用基于事件的完成模型的变体。在 2.0 版本中，您可以使用下列代码在某个套接字上启动异步发送操作：

void OnSendCompletion(IAsyncResult ar) { } IAsyncResult ar = socket.BeginSend(buffer, 0, buffer.Length, SocketFlags.None, OnSendCompletion, state);

在新版本中，您还可以实现：

void OnSendCompletion(object src, SocketAsyncEventArgs sae) { } SocketAsyncEventArgs sae = new SocketAsyncEventArgs(); sae.Completed += OnSendCompletion; sae.SetBuffer(buffer, 0, buffer.Length); socket.SendAsync(sae);

这里有一些明显的差别。封装操作上下文的是一个 SocketAsyncEventArgs 对象，而不是 IAsyncResult 对象。该应用程序创建并管理（甚至可以重复使用）SocketAsyncEventArgs 对象。套接字操作的所有参数都由 SocketAsyncEventArgs 对象的属性和方法指定。完成状态也由 SocketAsyncEventArgs 对象的属性提供。最后，需要使用事件处理程序回调完成方法。

所有这些更改都显著改进了 .NET Framework 3.5 中 System.Net.Sockets 类的性能和可伸缩性。现有应用程序可以自动实现其中的两项改进。第三项改进，即新型 Socket 方法，只能通过修改应用程序而得到使用，但这些方法都能为基于套接字的高要求应用程序提供更理想的可伸缩性。

一个Tcp版的EchoServer的示例如下：

class EchoServer { Socket server; public EchoServer(IPEndPoint localPoint) { server = new Socket(localPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp); server.Bind(localPoint); server.Listen(5); accept_async(); } private void accept_async() { var accept = new SocketAsyncEventArgs(); accept.Completed += accept_Completed; server.AcceptAsync(accept); } void accept_Completed(object sender, SocketAsyncEventArgs e) { accept_async(); var client = e.AcceptSocket; e.Completed -= accept_Completed; e.Completed += receive_Completed; var buffer = new byte[1024]; e.SetBuffer(buffer, 0, buffer.Length); client.ReceiveAsync(e); } void receive_Completed(object sender, SocketAsyncEventArgs e) { var client = sender as Socket; if (e.BytesTransferred == 0) { Console.WriteLine("socket is closed"); client.Close(); } else { client.Send(e.Buffer, e.BytesTransferred, SocketFlags.None); client.ReceiveAsync(e); } } }

 

转载者的话：

 

由此，我们可以大略窥探出.net3.5 Socket异步通讯性能之所以高于.net2.0的一个重要原因——极大的减少了因动态申请内存(new)而导致的性能急剧耗损。作为C#程序员，平时写程序时一定要注意这一点！