1

I'm trying to send a UDP packet to another server to notify it that new information is available. The data in the packet is fairly small, somewhere around 100 bytes, it's basically an event type and a UUID.

I'm aware of the limitations of how much information fits in a single packet (What is the largest Safe UDP Packet Size on the Internet) and it doesn't look like I'll have any issue with that. And I'm aware that UDP packets might get dropped - that's fine in my case, the packet is just a suggestion to optimize how quickly the other server(s) knows about new data, losing the packet will make the application respond slower but will not break things.

With that in mind, my question is how much does it matter what the size of that packet is? If I encode the information as JSON, it looks like it will be about 75-100 bytes. I can also encode the info in a raw binary form which will be much smaller (I can probably fit it in something like 30 bytes or less).

Is a UDP packet with a 100-byte payload going to travel "slower" than a 30-byte payload? I'm aware that each packet has an overhead, but it's not clear to me how much the packet size affects performance if I'm already avoiding fragmentation (which obviously would make things slower and less reliable). Could the size of the payload affect the likelihood of the packet being dropped?

In summary, I'm trying to decide if it's better to make a more cryptic but more compact format, or to go with JSON which will be easier to modify and maintain backward compatibility with as the application evolves, but definitely bigger in terms of the size of each packet.

Community
  • 1
  • 1
Brad Peabody
  • 10,917
  • 9
  • 44
  • 63
  • 1
    WIthin the limits you mention it doesn't matter much. You need to be aware that Ethernet also has a *minimum* size, so making it really small may not have any effect at all. – user207421 Nov 15 '16 at 22:35
  • Thinking about this a bit more, it seems to me that in cases where the network is not saturated, it would make virtually no difference. The packet would transmit and if it's longer it might take a relatively few more nanoseconds (roughly one nanosecond per bit on a 1Gb network). If these packets saturate the network, then that extra ~60% space could matter (by avoiding network saturation due to smaller size). Otherwise, it seems like it really wouldn't have any tangible effect. I don't think my use case will saturate the network at all, but I hadn't really thought about it. – Brad Peabody Nov 16 '16 at 00:25

1 Answers1

0

The size of the data talking about 100 Bytes or 30 Bytes, does not matter. It won't make your application lower or higher performance. Also the size does not affect the likeliness of a datagram being dropped at a router. Routers drop datagrams when there is congestion.

However, depending on your application, you may want to send more events in a single UDP message. Here there is a difference between 100 Bytes and 30 Bytes. A UDP datagram has an overhead of 20 Bytes for IP header and 8 Bytes for UDP header (+Ethernet header). In order to make better utilization of the network and CPU resources it's better to send more data per datagram, so with 30 Bytes you would be able to send ~3 times more data in a single datagram. This does affect performance. Sending N events in one datagram saves network resources and CPU resources (less messages, less message overhead, less interrupts, etc.), If you pack N events in one datagram the suggested limit per datagram is the MTU, which for Ethernet is 1500 Bytes, considering 20 Bytes for IP header and 8 Bytes for UDP header, you can send a payload of up to 1472 Bytes (14 events of 100 Bytes).

rodolk
  • 5,606
  • 3
  • 28
  • 34