Regarding UDP packets: Obviously I want to minimize the amount of data I need to send as much as possible. But, I also want to minimize the overhead for packet headers by bundling up the data into as few packets as possible. My question is, what is the best value to cap the max size of the packets at AND WHY? I see lots of suggestions, but they all vary and don''t have any explanation as to why that max size is chosen, so I''m having a really hard time making an informed choice as to the optimal max packet size. Thanks!

The best option is to leave packet size dynamic. There should be some algo. checking packet loss / resends / latency and adjusting size based on those figures keeping track of each connection seperately. The best option will vary from connection to connection based on distance line quality and the maximum packet size. I would have 3 settings, 4096, 8192 and 16384 bytes, then switch based on the packet loss / latency. It won''t be easy, but it isn''t that hard once you get into it and that''s the best way to do it.

I think the values that Mr. Stelly posted sound a bit high. I believe that you should try to keep your packet size below the MTU (Maximum Transfer Unit) size of the network segments between the client and the server. If a packet is larger than the MTU of a certain network segment, the segment will split the packet into several smaller packets that will all be transfered across the segment and reassembled again when the packet leaves the segment. Avoiding this splitting and concatenation procedure by staying below the MTU size is probably desirable if you want to maximize performance. A common MTU for ethernet networks is 1500 bytes and possibly less for shaky phone lines.

It would be really interesting to hear more about this from someone with experience in the field.

Henry

Wow, I haven''t seen even a single recomendation over 1k bytes until this message. That does sound very high to me, but I admit that I''m not really sure about what''s going on behind the scenes. I like the idea of dynamically adjusting the max size based on ploss. I''m looking forward to more posts about this.

Wow, Umh, that was a MAJOR typo on my part. I don''t know what exactly I was thinkin there, but that''s not what I meant...

Haha, I''m gonna have to put that on my blackboard somewhere as one of the dumbest things I''ve ever said. =)

Everyone who commented on that after me is right, 1500 bytes is as large as you would want to go, something like 500 1000 1500 maybe.

Sorry for the mix-up,
Jon

And now to get back to the original topic. Magmai is correct. If you figure that a 56k modem can reliably receive 4k of data per second, assume that it can receive 1k every 250 ms. So if you use a packet size of 1k, your minimum latency will be 250ms. In practice, there is some bursting, compression etc... that reduces that time by a lot, but lets keep this simple.

Assuming that 1k = 250ms to transfer, this would suggest that 250 byte packets would take around 60ms to receive. That would be pretty respectable. But in sending many 250 byte packets, you''re going to get a lot of packet overhead. Here''s a small breakdown of things to consider with packet size:

Small Packets (< 250 bytes)
---------------------------
Pros:
Resends require less wasted bandwidth
Packet loss results in less data lost
Lower latency on slow connections

Cons:
High packet overhead


Large Packets (> 500 bytes)
---------------------------
Pros:
Low packet overhead

Cons:
Resends are expensive
Packet loss results in larger amounts of data loss
Increases latency on slow connections


Somewhere in the middle there is a ''medium'' sized packet that is a balance between the 2 groups. You''ll just need to figure out which priorities and benefits are important to you, and which ones aren''t.

Right right, I''m pretty aware of the implications of going small/large but not sure enough on what''s going on behind the scenes. I think your first suggestion might make the most sense, adjusting the max packet size on the fly based on packet loss, capping it at like 1500 or so... A little more work but its probably better than generalizing since everyone is going to have a different quality connection.

aakks