一个关于C#中UdpClient使用Receive（）方法接受客户端信息的问题？！

send() receive()函数实现udp的发送接收，通常使用套接字的方式去实现。
IPEndPoint local= new IPEndPoint(ip, port);
receiveUdpClient =new UdpClient(local);// 将本机电脑ip、 端口封装成节点准备接收字节
//然后 建立连接 再接收由（IPAddressAny, 50000）传过来的字节数据 以byte[]形式赋给b
//通过解码获取发送过来的信息。
1IPEndPoint iep = new IPEndPoint(IPAddressAny, 50000);
while(true)
{
2 Byte[] b = udpServerReceive(ref iep);
}

多线程并不能提高执行效率，相反，由于多了线程切换，会有一丁点额外开销
多线程能提高交互和响应效率。
原因是cpu只能一条一条指令的做。
如果是多核编程或多处理器编程，那就肯定能快了。

1分布式结构VS星型结构，推送VS接收，服务端缓存VS客户端缓存。

RV和MQ都是分布式结构的，和JMS消息中间件的星型结构不同。分布式消息中间件的Server在应用环境里都会部署多个，彼此互联，没有主备之分。JMS消息中间件的应用部署一般都是主备两个Server，消息的发送和接收应用平时和主Server相连，有问题时切换到备Server，主备Server共用公共的存储设备来保存消息。

MQ和JMS消息中间件都采用消息接收端主动接收消息的方式。消息从发送端发出后，首先会缓存到Server上，接收端应用发起一个接收消息的请求，Server把消息作为应答返回给接收端。接收端不执行接收动作，消息就会一直在Server上保存。

RV和这两种消息中间件都不同，使用的是消息推送的模式。消息从发送端发出后，并不在Server上缓存，Server只做路由把消息推送给消息接收端。消息接收端只要连接上Server，订阅要接收的消息，这些消息就会源源不断地从Server那里推送过来，消息先缓存到接收客户端的队列里，接收端应用再从队列里取消息。

总之RV是一个分布式结构，推送消息模式，客户端缓存的消息中间件。分布式结构适用于分布是应用系统，方便做扩展，推送加客户端缓存适用于高实时性消息的处理，消息需要在第一时间到达目的地，过时的消息的没有必要保存下来的，消息接收端应用需要做的事情就是不断地处理已经推送到的消息。

2使用广播和组播来实现一对多的发布订阅。

MQ和JMS消息中间件在IP层都使用点对点的传输方式，而RV在IP层使用的是广播或者组播的方式。使用广播或者组播可以直接实现一对多的发布订阅形式，发布应用发布消息到RV网络上，这些消息会广播到网络的每一个节点上，每一个订阅应用都会收到这些消息。而MQ和JMS实现发布订阅就要麻烦的多了，都是在Server按消息的Topic来缓存消息，为每一个订阅者拷贝每一条消息的引用。当所有订阅者都从Server上取走某条消息，这条消息才在Server上删除。

3UDPVSTCP。

MQ和JMS消息中间件不论是Server和Server的通信，还是Server和Client的通信，在传输层都使用TCP协议，保证消息传输连接的可靠性。而RV在Server和Server之间的通信使用了UDP协议，牺牲可靠性来达到高实时性的需求。RV有两种可靠性级别，RVReliable和RVCM。RVReliable模式使用基于UDP增加了一定可靠机制的TRDP协议，在一定范围内具有消息包的检查和重传机制，保证了一定程度的消息可靠性，但不保证消息不丢失。RVCM在RVReliable基础上更进一步，在消息级别具有消息确认和重传机制，可以保证消息绝对不丢失。对于长度在1500个字节以下的消息，RVReliable发布消息能达到150万笔消息每秒，接收也能达到50万笔消息每秒。传输消息的性能是非常好的。

4使用消息Subject做收发两端的匹配。

MQ和JMS消息中间件在Server端按Queue和Topic来缓存消息，消息的发送端和接收端按Queue和Topic的名字来匹配。每个Server能创建的Queue和Topic是有限的，这也就限制了使用MQ和JMS消息中间件构建的应用，这些应用在做消息收发处理的时候只能使用粗粒度的消息分类。

RV不在Server端缓存消息，也没有Server端的Queue和Topic。它是使用消息的Subject来做消息发送端和接收端的匹配的。每个消息都有Subject，Subject格式是多个字符串的串接，没有数目或者长度的限制。比如在市场数据系统里，行情数据消息的Subject里包含金融品种的名字，这样的Subject可以有上百万个。消息订阅端可以细到只接收某个市场的某个品种的行情数据。

RV使用优化的算法实现Subject的筛选。如果RV网络上有一万种消息，一个RVServer被一千个消息接收端连接，每个接收端订阅不同的Subject。那RVServer的工作就类似一个超级的邮件分检员，对每一个从RV网络上广播而来的消息做Subject的判断，判断是否在这一千个订阅的Subject的范围内，是则将消息推送到订阅此消息的接收端，否则将消息抛弃。当数据量很大时，这种筛选工作是需要很高效率的。

总之，RV的最大特点是推送模式，把一个数据生产者的数据以最快的速度推送到多个数据消费者那里。RV从金融市场数据系统的需求中产生而来，正是这些特点使得它在证券系统得到最广泛的应用。

UDP服务器，就是首发数据，进行数据处理的。与TCP不同的是不用建立连接，直接调用recvfrom来收包。
开始就是基本的socket初始化地址什么的。
要求多个线程处理客户端命令，那recvfrom收包后，考虑把客户端的地址信息保存，便于sendto，对接收的数据包，交给线程进行处理，每个线程可以向一块共享内存、队列里写入收到的数据和对应的客户端信息，每次写的时候对这块共享资源加锁，多个线程对共享资源读是加锁，读完解锁，并开始处理数据。
处理完，用sendto发回去。
不是什么大项目。小程序而已。

说明：把广播地址改为服务器地址时接收正常
如果接收正常就OK了你发送到广播地址,接收到的是服务器发出的
发送 -> to 255255255255
接受 -> bind 0000 -> from server_addr
要不然就是你没有说清楚
---------------------------
你希望服务器收到自己的广播？那个不是保证可以正确的。不一定会收到几个，也可能没有。

---