granat: thanks for the clarification

Here''s a great list of the +''s and -''s of UDP and TCP/IP written by Andrew Kirmse (one of the lead developers on meridian 59)

I''m pretty sure that quake1 used UDP as well. I could be wrong.
I think the Net_udp.c file is a good indicator tho.

-=[ Megahertz ]=-

From ID''s quake tecnical support page.

quote:

---

Quake can be played over the internet using the TCP/IP protocol (here''s a graphical example) or on a local area network using the IPX protocol.

---

I must admit i''m not at all familiar with the Quake code. But knowing Carmack that could very well be net user data packet or a host of other things

Everquest uses UDP between client and server and TCP on the back end. I believe Anarchy Online was implemented using TCP. DAoC uses both. I believe Ultima Online originally used TCP, then switched over to UDP.

There is no number limit at which you decide to use one or the other. TCP will spike with 2 users as easily as it will with 100. It''s the nature of the protocol.

Most network programmers in the gaming industry openly shun TCP if they have a reliable UDP component available. And yes, holy wars have raged over this issue.

Ultima Online uses TCP.

Allright,

Say I want to use UDP for my game.
How about firewalls on the server side?

Quake uses UDP. The whole Internet protocol suite is called TCP/IP, which is why you sometimes see that even though they really mean UDP over IP.

I belong to the mailing list where I heard Brian Hook discussing the history of the quake network architecture developlment. I''ve located a link to the post in the list archives for your viewing pleasure.

http://www.kanga.nu/archives/MUD-Dev-L/2001Q4/msg00265.php

There''s two general approaches to take. Use a garuanteed protocol and minimize the data you send by using predictive encoding (i.e. temporal compression, e.g. hoffman encoded delta''s). OR use an ungaruanteed protocol and redundantly send the entire current state. You can still use hoffman encoding, but you can''t use temporal compression nor any other predictive encoders because you can''t garuantee that you have the previous update.

The advantage of the first method is that it minimizes data traffic. The advantage of the second method is that the game still works fine, even when you have 25% packet loss (or perhaps even higher). You can stay connected to EQ even with 75% PL, though gameplay is hampered.

There''s basically two types of infomation to send; status updates, and event notification. Current position and orientation are status updates; you could also broadcast health and such as status if it changes rapidally and is important. Buying stuff or trading equipment are events, as is the successful casting of a spell. Events always need to be garuanteed, but you can just stream/broadcast state information, and if the previous state packet didn''t make it, the next one will.

To send delta-states over UDP means you must implement your own reliable protocol ontop of UDP, and garuantee every packet! By sending delta states, you have decided to use predictive encoding, and you need every piece of prior state information inorder to correctly determine the current state.

Now, lets suppose a peice of status information didn''t make it, and we resend it. It''s way-out-of-date now, and we may have even received additional status packets after the dropped one. However, we can''t do anything with those status updates until we receive the lost packet.

You can take a hybrid approach, like mpeg2 video streams do, by sending a complete status packet every 500ms-1000ms and delta-status packets in between.

The advantage of TCP is that it''s done, works, and handles the general case. By using UDP you can program custom behavior in the event of lost information. If you''re looking to minimize game latency, and mitigate the effects of dropped packets on IP networks, then you need to dip into the TCP/IP stack lower than TCP. UDP seems to be where the current dip of choice is, but you can go lower still to the IP packet layer if you really wanted to. On a LAN you could skip the TCP/IP stack entirely, and use IPX which has minimal overhead when no routing is involved - less than the IP layer of TCP/IP.

quote:

---

Original post by Magmai Kai Holmlor
To send delta-states over UDP means you must implement your own reliable protocol on top of UDP, and guarantee every packet! By sending delta states, you have decided to use predictive encoding, and you need every piece of prior state information in order to correctly determine the current state.

---

This is where your a little bit off bud True, the Client does need to send an ACK for every delta state packet it receives. But the server does not need to resend state packets that the client misses. Why? because every packet sent from the server represents the delta between the last ACK''ed client state and the current server state. If the client recieves a packet containing state information it''s already received (by checking a time stamp or sequence num) it knows it needs to resend the ACK because the server did not acknowledge it. When the server receives the ACK it will know what information the client has received. The server just keeps firing away deltas based on the last ACKed state of the client. When it receives an ACK from the client, it updates it''s base state (for that client) and uses that to calculate new deltas from.

Yes it introduces some interesting issues, if the client does not ACK very often the delta packets could get quite large, potentially larger then the MTU. Also for each client connected to the server, you must store a little gamestate cache of sorts so that you can correctly indicate the base state when an ACK comes in. As each client may ACK different gamestate packets at different times.

Those issues aside, the system really does work. I''ve implemented it I’ve only tested it up to 4 players, with the server on my dialup connection. But it performed quite well