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.

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 :-)

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.