UDP编程实验
最近基于SNMP网络管理协议开发网管软件，SNMP协议传输层为UDP（port 161和162），网络上流行的C#版SNMP封装库SnmpSharpNet似乎不能够支持大规模（400台以上）网络设备管理，因为对udp通信模型封装的不够好。SnmpSharpNet虽然支持异步（Async）UDP传输，但是在业务上了利用_busy变量限制了发送接收同时并发的可能。
高性能的UDP传输，起码应该是多线程并发的，即多线程同时发送，多线程同时接收。本人对UDP编程的一些函数有些疑问，特做实验求解：
1> ReceiveFrom，作为阻塞模式，到底阻塞多久？
2> 多线程同时SendTo，可行吗？
3> 多线程同时ReceiveFrom，可行吗？
4> connect作用？
5> 再多线程同时send？
6> 再多线程同时receive？
1. ReceiveFrom
A．设置等待时间：_socket.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReceiveTimeout, timeout);只要在timeout ms时间内，收到数据，程序立刻往下执行；否则timeout ms后，程序甩SocketException中的超时异常。
B．此函数每执行一次，只接收一个UDP数据包。
C．使用UDP编程，一般应用程序需要实现超时重传，即多长时间未收到响应请求的数据包，再次发送请求。注意某种情况：请求命令1第1次，超时，请求命令1第2次，读到命令1响应，处理；请求命令2第1次，读到命令响应，这个响应可能是上次命令1的响应，也可能是此次命令2的响应，要解包分析。
2. 多线程同时SendTo
3. 多线程同时ReceiveFrom
实验1：
服务器SendTo发送请求，客户机ReceiveFrom，客户机接着SendTo，服务器ReceiveFrom返回响应，局域网耗时15ms（程序另有一些Console.WriteLine及DateTime.Now.ToString函数调用）。两台服务器对同一个客户端通信，没出现数据包发错，肯能是服务器数量还不够？
实验2：
在服务端，把SendTo和ReceiveFrom封装到一个函数Request中，启动三个线程，同时调用Request发送不同的数据请求。
Thread1_Request(“1234567890ab”); //回送” 2234567890ab”
Thread2_Request(“abcefg123”); //回送” bbcefg123”
Thread3_Request(“abc987123”); //回送” bbc987123”
接收端在接收到数据后，把首个字符+1，发送回服务器。我们希望同一线程中请求与响应的数据包对应，很遗憾，实际多线程接收时，线程2可能ReceiveFrom线程3的响应。如下所示一次3个线程并发过程：
Thread2 21:24:24.156接收：bbcefg123
Thread3 21:24:24.156接收：bbc987123
21:24:24.156接收：2234567890ab
Thread3 21:24:24.156接收：bbcefg123 //不是期望数据包
Thread2 21:24:24.156接收：bbc987123 //不是期望数据包
21:24:24.156接收：2234567890ab
Thread2 21:24:24.171接收：bbcefg123
Thread3 21:24:24.171接收：bbc987123
21:24:24.171接收：2234567890ab
Thread2 21:24:24.187接收：bbcefg123
Thread3 21:24:24.187接收：bbc987123
21:24:24.187接收：2234567890ab
Thread3 21:24:24.187接收：bbc987123
21:24:24.203接收：2234567890ab
Thread2 21:24:24.203接收：bbcefg123
Thread2 21:24:24.375接收：bbcefg123
Thread3 21:24:24.375接收：bbc987123
21:24:24.375接收：2234567890ab
21:24:24.375接收：2234567890ab
Thread3 21:24:24.375接收：bbc987123
Thread2 21:24:24.375接收：bbcefg123
Thread2 21:24:24.390接收：bbc987123 //不是期望数据包
Thread3 21:24:24.390接收：bbcefg123 //不是期望数据包
21:24:24.390接收：2234567890ab
经实验得出：一台服务器多线程同时对一台客户端通信，客户端响应服务器请求的数据包，在服务器接收时，同一线程的请求与响应会不对应，即本地UDP接收，谁先ReceiveFrom，接收区的数据包就被谁取走，而不管哪个请求的。
UDP模式下，多线程通信是，SendTo、ReceiveFrom不能同时封装在一个线程内，应该有独立的ReceiveFrom接收线程，对每次ReceiveFrom的数据包解析，从业务上识别出是对哪次SendTo请求的回应。如果发送、接收封装在同一个线程，超时重传机制容易实现，但是只能单线程通信了，大规模采集通信情况下满足不了。如果发送、接收各个独立线程，采集通信就可并发了，然而响应包是哪个请求、超时重传机制实现麻烦一些。
实验3：
单服务器单线程与通信客户端通信，服务器端线程代码如下：
while (true)
{
try
{
++moniNum;
_socket.SendTo(buffer, bufferLength, SocketFlags.None, (EndPoint)netPeer);
sw.Start();
Console.WriteLine("执行{0}次，时间：{1}", moniNum,DateTime.Now.ToString(("HH:mm:ss.fff")));
recv = _socket.ReceiveFrom(inbuffer, ref remote);
sw.Stop();
Console.WriteLine("{1}执行此段代码耗时：{0} ms", sw.ElapsedMilliseconds, moniNum);
}
catch (SocketException ex)
{}
if (recv > 0)
{
sw.Stop();
Console.WriteLine("{1}成功接收耗时：{0} ms", sw.ElapsedMilliseconds, moniNum);
}
}
客户端ReceiveFrom监听，一收到数据马上SendTo回给服务器。
运行结果如下：
执行1次，时间：09:39:30.656
1执行此段代码耗时：75 ms //75ms
1成功接收耗时：75 ms
执行1次，时间：09:39:30.734
1执行此段代码耗时：0 ms
1成功接收耗时：0 ms
执行1次，时间：09:39:30.734
1执行此段代码耗时：0 ms
1成功接收耗时：0 ms
执行1次，时间：09:39:30.734
1执行此段代码耗时：0 ms
1成功接收耗时：0 ms
执行1次，时间：09:39:30.734
1执行此段代码耗时：0 ms
1成功接收耗时：0 ms
执行1次，时间：09:39:30.734
1执行此段代码耗时：0 ms
1成功接收耗时：0 ms
执行1次，时间：09:39:31.156
1执行此段代码耗时：0 ms
1成功接收耗时：0 ms
执行1次，时间：09:39:31.156
1执行此段代码耗时：196 ms //196ms
1成功接收耗时：196 ms
执行1次，时间：09:39:31.343
1执行此段代码耗时：0 ms
1成功接收耗时：0 ms
疑问：为什么服SendTo->客ReceiveFrom->客SendTo->服Receive过程有大量的耗时0ms？有那么快吗？即使sw.Start()语句放在服SendTo之前，也是如此。
实验4：
服务器单线程封装SendTo和ReceiveFrom，线程中SendTo轮询各个客户端，ReceiveFrom各个客户端的响应。客户端监听线程ReceiveFrom数据后，立刻SendTo至服务器。
服务器期望：任意客户端ReceiveFrom的数据包是对其上一次SendTo的响应。
但是，如果服务器请求客户端1数据，超时，重发，还是超时，最后超时次数已过，服务器接着请求客户端2的数据，等待客户端2的回复，然而，如果这时收到了客户端1的UDP数据包，ReceiveFrom接收后，丢弃此包。本来等待客户2的ReceiveFrom机会，错过了。按程序，再次对客户2执行SendTo和ReceiveFrom。这有几个问题：A.其实没必要对客户2再次SendTo；B.如果对客户2再次SendTo了，它会回复两次，那么这两次又有一次会成为后面处理的多余负担；C.那么好点的方案应该是ReceiveFrom与SendTo分离，不绑定在同一个线程内；D.方案C有前提，准备接收客户2的回复时，无法对UDP接收区清除（能，这也还不够），超时后，网络再也不可能收到此次请求的回复数据包。
4. connect作用
5. 再多线程同时send
6. 再多线程同时receive