为WCF增加UDP绑定（实践篇）

这两天忙着系统其它功能的开发，没顾上写日志。本篇所述皆围绕为WCF增加UDP绑定（储备篇）中讲到的微软示例，该示例我已上传到网盘。

上篇说道，绑定是由若干绑定元素有序组成，为WCF增加UDP绑定其实就是为绑定增加UDP传输绑定元素，最终目的是在信道栈中生成UDP传输信道。因此我们定义一个类UdpTransportBindingElement，它继承自TransportBindingElement表明这是传输相关的绑定元素。示例中该类还实现了IPolicyExportExtension和IWsdlExportExtension接口，关于这两个接口，我知道它们的作用，但看到代码却是一头雾水，我认为要能理解这块内容首先要对WSDL相关的各种规范做一详细了解，目前我先不考虑。对这有兴趣的朋友可阅读蒋大牛的元数据架构体系全景展现。以前总觉得WCF不外如是，不成想这水也太特码深了（WCF相关的概念有很多，包括ChannelDispatcher、ListenerHandler、ChannelHandler等，这些和消息传输关系不大）。

UdpTransportBindingElement主要负责绑定管理类的创建工作，服务器端和客户端分别创建的是UdpChannelListener和UdpChannelFactory。UdpChannelFactory的实现比较简单，我们重点看UdpChannelListener实现。网上资料都有类似这么一段描述：ChannelListener负责监听消息，一旦消息抵达则使用对应的Channel接收消息。在UDP解决方案中，消息监听依赖System.Net.Sockets.Socket类，示例中调用该类的BeginReceiveFrom方法进行异步监听。

 1 void StartReceiving(object state) 2 { 3     Socket listenSocket = (Socket)state; 4     IAsyncResult result = null; 5  6     try 7     { 8         lock (ThisLock) 9         {10             if (base.State == CommunicationState.Opened)11             {12                 EndPoint dummy = CreateDummyEndPoint(listenSocket);13                 byte[] buffer = this.bufferManager.TakeBuffer(maxMessageSize);14                 result = listenSocket.BeginReceiveFrom(buffer, 0, buffer.Length,15                     SocketFlags.None, ref dummy, this.onReceive, new SocketReceiveState(listenSocket, buffer));16             }17         }18 19         if (result != null && result.CompletedSynchronously)20         {21             ContinueReceiving(result, listenSocket);22         }23     }24     catch (Exception e)25     {26         Debug.WriteLine("Error in receiving from the socket.");27         Debug.WriteLine(e.ToString());28     }29 }

需要关注Socket.BeginReceiveFrom方法，MSDN有一段描述：当应用程序调用 BeginReceiveFrom 时，系统将会使用单独的线程来执行指定的回调方法，并将在 EndReceiveFrom 上一直阻塞到 Socket 读取数据或引发异常为止。但示例中有判断该方法是否同步执行的代码，因此我认为该方法并不会每次都用异步的方式来进行数据的接收，具体请看我的另一篇文章关于IAsyncResult接口的CompletedSynchronously属性。

不出意外，当数据抵达后采用Socket.EndReceiveFrom获取。我看到这里的时候觉得有点不对劲，不是说“ChannelListener负责监听消息，一旦消息抵达则使用对应的Channel接收消息”吗？既然ChannelListener都把数据接收完成了，还要Channel何用。此处似乎Channel真的只是走个过场，它存在的意义只是因为WCF框架需要它。所以我们还是需要将已接收的消息从ChannelListener传递给Channel，于是我翻看代码，希望找到一个event，在消息接收完毕后触发，以便Channel能实时得到消息可用的信号，结果没找到哪怕一个event的声明，于是我苦恼了。

 1 public interface IInputChannel : IChannel, ICommunicationObject 2 { 3     EndpointAddress LocalAddress { get; } 4  5     IAsyncResult BeginReceive(AsyncCallback callback, object state); 6     IAsyncResult BeginReceive(TimeSpan timeout, AsyncCallback callback, object state); 7     IAsyncResult BeginTryReceive(TimeSpan timeout, AsyncCallback callback, object state); 8     IAsyncResult BeginWaitForMessage(TimeSpan timeout, AsyncCallback callback, object state); 9     Message EndReceive(IAsyncResult result);10     bool EndTryReceive(IAsyncResult result, out Message message);11     bool EndWaitForMessage(IAsyncResult result);12     Message Receive();13     Message Receive(TimeSpan timeout);14     bool TryReceive(TimeSpan timeout, out Message message);15     bool WaitForMessage(TimeSpan timeout);16 }

从IInputChannel的定义可以看到，什么时候接收消息，什么时候等待，是不可控的，因为这些方法可以外部调用（一般是WCF框架自己调用）。简单地说，就是IInputChannel本身获取消息采用的是拉模式，而非推模式。为什么WCF框架不使用event模式（推模式）呢，我没有深入研究过，有知道的朋友还望赐教。这些方法调用时间不知，但若有可用消息时，不论何时调用Receive方法，我们都应该返回正确的Message，换句话说，从消息抵达到获取消息，可能有个时间差，这段时间内，消息数据不能丢失，于是我们应该有个临时存储消息数据的地方。考虑到消息数量和处理顺序，先入先出队列是个不错的选择。不出所料，示例中有个InputQueue类，该类相当复杂，不过万变不离其宗，UdpChannelListener将接收到的消息存入InputQueue，UdpInputChannel从InuptQueue中Receive消息。弄清楚这个，我便释然了。

上述模式只是实现消息从ChannelListener到Channel传递的其中一种方式，只要按规范实现WCF框架提供的关键接口，我们可以使用能想到的任何方式，比如使用event将消息接收工作转移到Channel类（更符合WCF对Channel的职责说明），当然接收到的消息仍旧需要用Receive方法去某个地方读取，因此消息的临时存储仍然必不可少。

由于最近比较忙，就先写到这里吧。示例中最核心的就是ChannelListener、InputQueue和AsyncResult类，AsyncResult类的作用也在关于IAsyncResult接口的CompletedSynchronously属性中有过阐述。若是全面铺开就太多了，有兴趣的朋友可以下载代码自己研究，有什么心得体会欢迎一起讨论。

转载请注明本文出处：http://www.cnblogs.com/newton/archive/2012/11/29/2793931.html