关于LWIP中UDP数据收发文件接收的问题

cxy123321

根据原子哥的UDP通信例程，为什么接收超过5K的数据就进不了回调函数？我能解释的就是pbuf只有10个，每个512B一个，所以总共5K，所以我试着增加了pbuf个数，确实可以接收的UDP数据也增多了，到了差不多有10K，不过也算是封顶了，不能再多了，所以可以解释为pbuf耗尽吗？当然，也可以增加pbuf缓存的大小，不过关注点不在这，而且耗内存。
于是我试了下用TCP进行传输，结果是没问题的，通过对TCP的接收发现在接收到1帧数据(1460Bit)或者说每接收到1帧数据后触发DMA中断，中断处理中会去内存池申请pbuf，1帧数据需要申请3个pbuf才能容纳，申请并传输完成后，pbuf会在TCP的接收回调函数中被释放，继续等待下1帧数据的DMA中断的到来，再从中重新再申请3个pbuf，也就是说在TCP的接收过程中，pbuf一直处在被申请-被释放的循环中，整个过程中最多都只需要同时占用3个pbuf，却可以接收非常庞大的数据量，试着传了50几K的数据都没问题。
反观UDP的，我发现说一旦进入DMA中断(接收到1帧1472Bit)，只要数据量超过5K便会一口气将10个pbuf全申请完，然后发现一直申请不到足够的pbuf去容纳数据，所以也就进不了UDP的接收回调函数了，可是一个数据帧顶多也就1472字节，理论上应该跟TCP接受过程一样，为何会一下子吧pbuf耗尽了？如此说来要是我UDP数据再庞大一点，那就算有再大的内存池也不够它消耗吧，一口吃不成大胖子呀。
明明用的是同一个DMA中断处理过程，为什么UDP就会出现这样的问题呀，难道是UDP没有像TCP的确认机制，在第一个数据桢刚刚进行完DMA中断处理过程，pbuf还没来得及去回调函数中处理并释放的情况下，下一个数据桢便到来并触发了新的DMA中断？
问题1MA描述符所指向的数据缓存区有大小限制吗？在程序里没找到呀。按照MTU为1500来算，随便来一个数据包是不是只用一个描述符就可以解释了？并不存在多个描述符解释一个数据包的情况嘛，我发现在描述TCP报文时加上帧头尾以后的DMA描述符指向的数据区就是1500字节。
问题2:不考虑问题1的情况下，DMA中断的触发是当收到一个描述符才触发还是当收完1个由n个描述符解释的数据桢时才触发？我发现说例程中在每次中断里好像只对1个描述符进行了pbuf申请
问题3:为啥我的UDP数据总长不超过5K？
刚刚学LWIP，有很多还不理解，有可能我上面说的有哪里是理解错的，没说清楚的，不过基本上问题就是这样了。
（注：代码基本上没做啥修改，就是原子哥的UDP例程，我主要是想要在不考虑可靠性的情况下，试着用UDP传个文件，有可能十几二十K甚至更大，现在TCP可以了，就是UDP老是出现这个问题）

cxy123321

没人理我，这是一个属于我自己的帖子！UDP是有界的，适用于单包传输，如果一次传输过多的数据包会造成阻塞丢包。所以如果要用UDP进行大文件的传输必须借助外部协议，一咕嚕丢过去整个文件只适用于TCP数据流，不适用于UDP。

cxy123321

对了，忘了说了，我指的是  探索者 的例程  STM32F407

dd777

看了楼主的贴，对TCP了解更深，请教一下最后罗列的三个问题得到答案了吗