UdpClient的Connect究竟做了什么(转)

最近在写一个音频通信的系统，因为需要还要处理其他事件，所以就自己设计底层的通信协议，用了不少底层的Socket编程（.Net Framework），搞清楚了不少细节问题。

先做一些铺垫工作。音频系统服务器需要给所有的客户端发送音频。服务器端要记录下连接的客户端的IPEndPoint（也就是IP+端口号），然后会对所有连接的客户端群发。因为客户端很可能是在NAT后的，所以不可能直接用向某个地址的Udp客户端发送连接。所以客户端需要把第一条消息发送给服务器端，NAT服务器就会打开一个口，允许服务器端向这个客户端发送包（这就是最简单的所谓的“Udp打洞”技术）。当然这个端口不会一直保留，一般不用的话很快就会被关闭。不过传输实时音频一般都会连续使用的，所以不用太担心这个问题。

所以客户端先要向服务器发送一条消息，服务器端看到这是要求接受的消息后，就会把获得的IPEndPoint加到群发列表中。服务器端的监听UdpClient要Bind到一个端口，它只需要考虑接受消息。另一个UdpClient来发送消息，而这个不指定发送目标也没有绑定到端口的UdpClient，需要在发送时指定消息目标，或者用Connect方法，来指定某个默认目标。服务器端因为要向不同的目标发送，所以不用Connect。

但是客户端的UdpClient却需要首先作为发送端，然后再作为接受端。因为在发起第一个发送的时候，操作系统会自动选取一个端口号，因此我们就希望客户端能在此监听。但是客户端发送时只跟服务器的某个IPEndPoint通信，所以一开始我就用Connect连接到服务器的IPEndPoint。几乎所有的文档都说，Connect基本不做什么事情，它只是设置Send的默认接收端，免去每次发送都指定接收端的麻烦。但是Connect其实还做了一件事，导致客户端接收不到服务器发送过来的消息。是什么呢？

因为Connect也把该UdpClient所能接受的消息来源限制为所连接的接受端。但是服务器端的发送却是另一个UdpClient执行的，它的端口号是由系统随机分配的，而不是监听消息的UdpClient。所以客户端的UdpClient就不能接受到这个消息。所以这种需要连接一个UdpClient，却需要接受另一个UdpClient消息的情况，就不能使用Connect了。解决的办法是直接使用SendTo（Socket方法）或者UdpClient指定目的的Send方法的重载。

但是能够用同一个正在Receive的UdpClient同时发送数据吗？按说应该可以，但是没有试验过，有经验的大牛直接告诉我得了。而且对于使用了线程的服务器来说（使用.Net的异步编程模型潜在使用了线程池），用一个UdpClient来做所有的工作，总是担心会出现并发访问问题，或者出现并发导致的效率损失。所以为了保险起见，还是各做各的事比较好。

如果在局域网，或者以后大家都用IPv6，就没有这些复杂的问题，直接客户端开一个端口监听就行了。服务器只要知道IP，就可以向默认的端口发送消息。多么美好的景象！