在接收缓冲区几乎已满时停止部分切断UDP数据包 我正在致力于C++中实现滑动窗口协议的分配。我正在使用UDP（SOCK_DGRAM）套接字。有时，程序必须背靠背发送大量数据包（与窗口大小一样大）。到目前为止，我还没有将窗口大小增加到超过30个，但最终应该可以达到256个。数据包的大小必须取自用户输入，因此可以是任何合理的大小。当数据包大小很小时，比如512字节，就不会有问题。当数据包的大小较大时，如40KB，前几个数据包被正确读取，然后我的readNBytes（）函数在只读取其中一部分数据包后突然挂起。我假设操作系统的接收缓冲区被填满，其中一部分数据包被丢弃。将其放入缓冲区的部分读取，然后readNBytes（）等待其余部分，其余部分被操作系统丢弃

发生这种情况时，操作系统是否设置了任何标志供我读取？理想情况下，如果数据包不适合接收缓冲区，我会强制操作系统丢弃整个数据包，而不是只接受其中的一部分。我的系统上没有定义IP_DONTFRAG，因此我不知道如何执行此操作。我也会满足于将接收缓冲区的大小设置为数据包大小的倍数，这样数据包就不能部分地放入缓冲区。克服这个问题的最佳方法是什么

如果您的

recv（）

缓冲区对于数据报来说太小，它将被截断。它不会导致阻塞

---

你的数据报太大了。IPv4限制为65507字节，但普遍接受的实际限制为534字节。您当然应该将它们保持在路径MTU下，否则您将保证碎片化，这只会增加数据报丢失的机会。

操作系统不会将半个数据包传递给应用程序

IP负责处理发送端的碎片，IP数据包可以高达64K，并将通过IP进行碎片化，以适应底层的MTU

---

在接收端发生相反的情况，即重新组装。使用UDP，您要么接收整个数据包，要么什么也不接收只接收其中一部分的唯一原因可能是您的应用程序接收缓冲区很小。一些套接字实现将其切碎，即使所有内容都已接收到

IP数据包的最大大小通常约为1500字节。使用可高达9K或10K的巨型帧。所以512字节的数据包大小并不小，40K的数据包大小是前所未闻的——至少目前是这样。@CraigS.Anderson我认为最大IP数据包大小是~65KIP数据包的绝对大小限制是64K。实际上，在没有巨型帧的情况下，限制为1.5K，而在巨型帧的情况下，限制为9K左右。请记住，IP数据包需要装入以太网、802.11x、令牌环等帧中。操作系统不会将半个数据包传递给应用程序。IP负责处理发送端的碎片，IP数据包可以高达64K，并将通过IP进行碎片化，以适应底层的MTU。在接收端发生相反的情况，即重新组装。使用UDP，您要么接收整个数据包，要么什么也不接收。只接收其中一部分的唯一原因可能是您的应用程序接收缓冲区很小。有些套接字实现将其切碎，即使所有内容都已收到。@PhilipStuyck-由于主机可以丢弃大于576（v4）或1500（v6）字节的碎片数据包，因此发送64k数据包不是最好的主意。问题在于我的readNBytes和writeNBytes函数。我已经在基于连接的套接字上使用它们好几个月了，但我忘记了它们会分解数据块并在另一端重新组装。每个片段都作为数据报单独发送，当缓冲区填满时，一些片段丢失。这个答案帮助我发现了这个错误，告诉了我什么是我不需要担心的。