Actually, I''ve thought of doing that instead of my current implementation of reliable UDP. I don''t know if it is good or bad or whatever though.


http://druidgames.cjb.net/

How did you implement UDP to be reliable?

It''s pretty much what I''ve done. I have several classifications of packets, unreliable, reliable, and ordered, each gets its own treatment. Each packet is caches in a linked list until it is acknowledged. If a packet isn''t acknowledged after a certain amount of time, it is resent. Each time a packet is recieved, it is cached until it is allowed to be used. If that packet has already been recieved or is currently cached, another acknowledgement is sent, and the packet is discarded.


http://druidgames.cjb.net/

I don''t know if it is good or bad, I will let someone else try to answer that one.

I do know that it is possible to implement your own guaranteed (reliable) packet delivery system for UDP, infact such a question was posted here recently and a good response was given on how to do it. I also know that DirectPlay 8 seems to send all its messages in UDP packets. This would suggest to me that UDP/IP is perhaps the better solution.

I believe that TCP/IP uses smaller protocol headers but the delivery times can be slow. UDP/IP uses much larger protocol headers and there is no guarenteed delivery or order. But it is much faster.

From every thing I have read I would suggest that UDP/IP with your own delivery mechanisems would be a better solution.

Some one suggested deleting out of order messages, would it not be better to buffer all messages and re-order them locally. Surely this would be quicker than waiting for the resend mechanisim to kick in as well as saving bandwidth.

I think it really depends on what you''re being routed through on the way from client to server and back. It''s just a matter of chance most the time. I would try to test it out, but my network always has under 10ms pings, and I can''t get it to lose a UDP/IP packet no matter how hard I try (I never thought I''d be upset about reliability ).


http://druidgames.cjb.net/

OK, lets not get into the Microsoft love hate argument. At the end of the day what they do is succesfull (even if there methods are questionable), you can''t argue with that. Although I don''t claim to be a big fan of MS they have made my life as a software engineer much easier.

If you don''t want to accept my statement of MS using UDP as the base protocol for DirectPlay. How about:

"Unreal''s Internet support is based on UDP, the standard Internet protocol for unreliable, connectionless communication. All Unreal gameplay coordination between a client and server goes through one constant, unchanging pairing of UDP addresses (where the client and server each have a 32-bit Internet address and a 16-bit port number)." Taken from - http://unreal.epicgames.com/Network.htm

Quake II also appears to use UDP. Half-life which is based on a heavily modified Quake II engine uses UDP. if you check out an article at Gamasutra entitled "Half-life and TeamFortress Networking: Closing the loop on scalable network gaming backend services" they actually discuss the problems they had and metioned that they use UDP as there base protocol.

I don''t know what the speed differences are between TCP and UDP. If your going to try and measure them perhaps you could post your results for use here, I would be interested in knowing what you come up with. The main problem with measuring these quontities is that on a LAN the values are genereally small and the differences insignificant and accross the internet, as was stated by "Null and Void" it really does depend on the jeourny the packet takes, what hardware and software its passing through on its way, even what time of day it is. Its not something that you can provide an accurate measurement for.

Generally if you keep your bandwith usuage down, you''ll be helping to keep your latency down.

Anyway, at the end of the day. If you are basing your code on fixed measured values then there is something wrong with your approach. Latency is a fact of life when it comes to network programming. You have to live with it and adjust to it, real-time if necessary. I''ve played a lot of online games and seen them tollerate verying degrees of latency.

Quake III Areana generally becomes unplayable for me above a 500mSec delay but I have seen people persist at upto a seconds lag, on screen it looks terrible.

Half-life (Teamfortress, Counterstrike) Seems ok upto about 800mSec but you start noticing strange things from about 300 mSecs.

You have to consentrate your efforts on making the user believe there is no lag for as long as possible and build into your system graceful degrigation. It also depends on your game type, I think any real-time game capable of handling anything above 500mSecs is doing well.

Out of interest:

TCP/IP has a header of 6 bytes.

UDP/IP has a header of 28 bytes, (unreal include there own 5byte header which means for them their header was 33 bytes)