I read that you shouldn't send UDP packets that contain small amounts of data in the "The Internet Sucks" article because of uncompressed packet headers. But that seems doesn't sound right
That article sucks.
Anyway, the statement is not intrinsically wrong - you will hose bandwidth with small packets if you're not careful. A UDP packet has 22 bytes overhead, and if you send a single 4 byte number (java int) in each packet then you're wasting 3/4 of your b/w!
This is trivial to fix, though, you just batch your messages up to a configurable threshold. Set up a heuristic e.g.
- I have less than 100 bytes of data to send
- the first byte of data came in less than 5 milliseconds ago
batch the data and don't send it yet"
This 5 ms wait would be invisible to players, on their minimum 30ms latency even for an almost directly-connected fast broadband connection - but it would spare you some b/w. Very significant if you have a lot of traffic.
But...it depends from game to game whether it matters enough to bother going to that length!
Also, I'm trying to design a method to ensure the arrival of packets when using UDP.
Welcome to the pain of why I strongly advise no-one to write their own protocol on top of UDP!
Short answer: go read the internet RFC's that describe how TCP works. That includes all the detail you ever need on hwo to do retransmit.
Especially do NOT try and muck about thinking you're cleverer than the desingers of TCP - take it from me, you're not. Just implement what they did. Chances are, if you try and cut a corner, it'll come back to bite you on the ass some time in the future...
Finally, a warning: sometimes all the above advice is wrong. I had to make some assumptions about your project, and if I assumed wrong, then I could be telling you the wrong stuff. C.f. SWP who had a very unusual (as far as games are concerned
) protocol, and several standard assumptions no longer applied.