c# 用udp通信时,如果较长时间再Receive，会读到很早之前的旧数据吗？
也就是socket有没有把所有没读的数据，缓存在交换机。如果这个数据没有来读，下次来读，优先发这个旧的数据，是排队发的？
前面已经说了，udp无连接，非可靠。丢包，乱序正常
非广播组播的udp经过路由，路由会探测一下目标机器和端口在不在，在就发。不在就丢。（不在判定也不是很严格，就像前面那位说的，如果网络拥堵，探测包无回复，他就丢）
同样乱序也正常，路由转发时候探测的回复到达顺序不可知，A包比B包先到，探测包后到，那么他实际转发比B晚
至于广播组播的，那种是在网络上乱窜的，TTL生存期到达之前他们会在网络上乱窜，所以接收顺序就更是拼人品的事情
然后把socket本身默认并不是断开就立刻断开的，端口其实还会默认保留一段时间，所以虽然你代码感觉断开了，但实际接收缓存实际还在继续接收
就像前面那位老兄说的，我们其实不靠程序判定，我们通过抓包程序判定，抓包程序是直接桥接在网卡驱动上的。所以网络上收到啥就是啥，如果你的抓包程序就是几分钟后收到的，那么他就真的是几分钟后收到的
ps:不过我奇怪的事情是，上个帖子已经说了。就你的项目而言1m就要来一次的东西，一个永不关闭的udpclient，一个永远异步接收就好。
有怎么存在“较长时间再Receive”的事情，我不关闭udpclient，他永远保留本地端口（因为你还有一个1m一探测的主动查询，所以路由器还不会主动断开死路由信息），所以只要路由转发过来了，你就立刻收到，根本就不存在“较长时间再Receive”这种事情
socket数据并不是按队列缓存在交换机中的。交换机是负责将数据包从一个端口转发到另一个端口，它没有缓存数据的功能。数据包在传输过程中可能经过多个交换机和路由器，但它们并不会被缓存在这些设备中，而是在传输中不断被转发，直到到达目的地。在传输过程中，数据包可能会被缓存在发送端和接收端的网络设备中，以保证数据的可靠传输。
不知道你这个问题是否已经解决, 如果还没有解决的话:内存中的多字节数据在存储式有大端存储和小端存储之分，网络数据流同样会有大端小端的区别，所以我们要如何定义网络数据流的地址呢？
为了让网络程序具有可移植性，C语言提供了库函数，帮助我们将网络字节序和主机字节序进行转换。
#include <arpa/inet.h>
uint32_t htonl(uint32_t hostlong);
uint16_t htons(uint16_t hostshort);
uint32_t ntohl(uint32_t netlong);
uint16_t ntohs(uint16_t netshort);
其中函数名中的h表示host即本机，n表示network即网络，l表示long即32位长整数，s表示short即16位短整数。
htonl就表示将本机上的32位长整数从本机字节序转换成网络数据流的网络字节序。
不论大小端机器，只需要记住只要从网络字节流中读取出来的一定是大端字节序，再根据本机的存储方式，选择是否继续进行操作即可。
如果本机是大端机，那么这些函数不会做什么转换，会将参数原封不动地返回。
如果本机是小端机，那么这些函数就会帮我们完成小端字节到网络字节序的转换工作然后返回。