OK, whats the ideal packet size? Im making a file update server, and lets assume at some points ill be sending files around 1 mb, so it will necessitate many packets. 1024?

Also, what is the best method? Should the server just keep chucking packets at the client? Should the client ask for them sequentially?

If you''re going to be transfering files, just use TCP (or some other stream oriented protocol) and don''t worry about the packet sizes.

Yeah, you could use TCP and not worry about it. However, I made the decision in my game to go UDP exclusively rather than use a TCP/UDP hybrid. So if you go that way like I did you'll have to worry about packet size.

In my game, patching packets are 1K each, and this seems to work pretty well. Actually UDP will possibly split apart any packet over 512 bytes, so I have a somewhat increased chance of packet loss. But I have a reliability layer built into my packets, and patching is not a time critical process anyway, so I figure if I lose the occassional packet, it's no big deal.

So the bottom line: Use TCP and you don't have to worry about it. Use UDP and keep them < 512 bytes to have the best chance of them getting there, or use UDP > 512 bytes to have less chance of them getting there but more data sent at a time.

For me, 1K at a time worked out well. YMMV.

quote:

---

Also, what is the best method? [...] Should the client ask for them sequentially?

---

This is what I do. The client first asks for a list of files to update, then asks for each one at a time in 1K chunks, updating it's internal list as it gets each part.

In general, the client should almost always initiate a request, never make the server the initiator. There are times you have to break that rule, but where you can you should try to stick with it.


[edited by - RonHiler on December 12, 2003 10:55:35 AM]