c++ - What is the optimal size of a UDP packet for maximum throughput?

Question

I need to send packets from one host to another over a potentially lossy network. In order to minimize packet latency, I'm not considering TCP/IP. But, I wish to maximize the throughput uisng UDP. What should be the optimal size of UDP packet to use?

Here are some of my considerations:

• The MTU size of the switches in the network is 1500. If I use a large packet, for example 8192, this will cause fragmentation. Loss of one fragment will result in the loss of the entire packet, right?

• If I use smaller packets, I'll incur the overhead of the UDP and IP header

• If I use a really large packet, what is the largest that I can use? I read that the largest datagram size is 65507. What is the buffer size I should use to allow me to send such sizes? Would that help to bump up my throughput?

• What are the typical maximum datagram size supported by the common OSes (eg. Windows, Linux, etc.)?

Updated:

Some of the receivers of the data are embedded systems for which TCP/IP stack is not implemented.

I know that this place is filled with people who are very adament about using what's available. But I hope to have better answers than just focusing on MTU alone.

Answer 1

Alternative answer: be careful to not reinvent the wheel.

TCP is the product of decades of networking experience. There is a reson for every or almost every thing it does. It has several algorithms most people do not think about often (congestion control, retransmission, buffer management, dealing with reordered packets, and so on).

If you start reimplementing all the TCP algorithms, you risk ending up with an (paraphasing Greenspun's Tenth Rule) "ad hoc, informally-specified, bug-ridden, slow implementation of TCP".

If you have not done so yet, it could be a good idea to look at some recent alternatives to TCP/UDP, like SCTP or DCCP. They were designed for niches where neither TCP nor UDP was a good match, precisely to allow people to use an already "debugged" protocol instead of reinventing the wheel for every new application.