Sending large datagrams in FreeRTOS+TCP

I have large datagrams I’d like to send over UDP, and in investigating why they weren’t being sent I realized that FREERTOS_sendto() caps the size of datagrams at the payload size for a single packet. It should be possible to allow fragmentation at the IP leve,l for reassembly at the destination. I saw this config option ipconfigCANFRAGMENTOUTGOING_PACKETS that seems to allow exactly what I need. But it appears not to be implemented in +TCP. Is there any plan to include this functionality in +TCP? As an alternative, I considered increasing the MTU, but it would be memory-prohibitive as I need to send datagrams up to 24Kb, and I’m also not sure about the hardware level support for that. So now I’m considering if I need to implement a fragmentation and reassembly as a part of my own protocol, but that would be somewhat unfortunate. Thanks for any help.

Sending large datagrams in FreeRTOS+TCP

Hi Justin, In the earlier FreeRTOS+UDP stack there was indeed an option ipconfigCAN_FRAGMENT_OUTGOING_PACKETS. That stack is still distributed along with the kernel, e.g. : ~~~ FreeRTOSv9.0.0/FreeRTOS-Plus/Source/FreeRTOS-Plus-UDP ~~~ As the option says, it will only work for outgoing packets, which is enough for you. When developing +TCP, it was decided to stop supporting UDP packet fragmentation. That decision saved a lot of code and it made the code easier to read. And in fact, TCP can do exactly what you need: split up and join packets in a reliable way. You can set MTU to 1500, or a little bit longer in case your peripheral, switches and router support jumbo packets. So you can use TCP, or, alternatively, give your UDP packets a small header and make your own fragmentation. That should not be too difficult 🙂

Sending large datagrams in FreeRTOS+TCP

Thanks for the info. I must say you have succeeded in making +TCP very readable. The nice thing about UDP is that I can broadcast datagrams and listeners can listen as they want or are able. But since I also need and use TCP for more connection-oriented comms, using just +UDP isn’t an option. I’ll look into breaking up and reassembling UDP at the application level then.