Generally speaking it's best to keep UDP packets down in the <=~500 byte range, but it's possible to make them up to ~1500 bytes in size. Each packet contains the _entire_ message you're sending.
Regarding buffer size (from the original thread): that's for TCP RX buffers. TCP streams data across multiple packets and buffers the stream in memory. UDP doesn't know if one packet is related to another packet.
What is the size of data you're trying to send via UDP? [Perhaps we need to add an extra exception instead of failing gracefully somewhere here.]
P.S. I've repurposed UDP before for streaming data. If you add a sequence # to the front of your UDP packets, you can reassemble them on the other side. But unless there's a really good reason to do this manually, use TCP: it does this for you.
Right, thanks Chris. I'm a bit rusty getting this low down in the network stack, I can make broadcasts with TCP, right? If so then that would be the way to go.
My data is of indeterminate size because I'm serializing to JSON and it can depend on things like the length of strings, how many decimal places numbers have and so on. If I took a worst-case maximum it would be well over 1500 bytes. So it looks like TCP is the way to go.
I definitely think you should throw an exception if you can't complete the request that the user has given you.