🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
A Couple of UDP Questions
Author
I''ve read quite a few articles on multiplayer game programming and it seems, that Client/Server UDP protocols are definately the way to go.
I''ve got some TCP programming experience but no knowledge of UDP. As far as I can tell it shouldn''t be too hard to add some basic checking to make sure the UDP packets are received.
BUT, there are a few things that I''m not sure about that would influence the coding of this.
1. If you send data over TCP the OS often either breaks the data into smaller packets or puts multiple transmissions into one packet to increase performance. Does this happen with UDP aswell or does each block of data you send actually go in one UDP packet?
If it doesn''t, how can I determine if a block has had one of its packets dropped/re-ordered?
The obvious way to do this is to record a sequence number, type and checksum with each data block. Therefore you check the number is in sequence, you know how much data to read in from the type and use a checksum to verify the block isn''t damaged (for example if the packets was re-ordered during transmission).
BUT what happens if one packet goes missing in the middle of one of these "blocks" of data? The checksum will fail, but how will you know how much data has gone missing? Where do you start looking for the next structure?
Thanks
UDP won''t break up packets or merge packets. If you call send() (or whatever) 10000 times with 1 byte each time you''ll get 10000 packets on the wire. If you''ve got something to send that''s bigger than one packet you need to break it up yourself.
UDP has less overhead than TCP. The price you pay is reliability. If you send four packets 1-2-3-4 you could receive them as 1-3-4-2 (reordered), 1-2-2-3-1-4 (duplicated), 1-4 (dropped), etc.
The first step to getting around those problems is a sequence number as you said. If you get a packet with a sequence number that is below the highest valid one you''ve received then you know that this is a duplicated or excessively late packet. You catch dropped packets by using timeout. If the packet you''re waiting for doesn''t get there after 5 seconds (say) then ask the sender to send it again. You can also try to work around these issues at the protocol level (e.g. sending redundent data).
I recommend searching the web / looking at books for "sliding-window" protocols.
-Mike
UDP has less overhead than TCP. The price you pay is reliability. If you send four packets 1-2-3-4 you could receive them as 1-3-4-2 (reordered), 1-2-2-3-1-4 (duplicated), 1-4 (dropped), etc.
The first step to getting around those problems is a sequence number as you said. If you get a packet with a sequence number that is below the highest valid one you''ve received then you know that this is a duplicated or excessively late packet. You catch dropped packets by using timeout. If the packet you''re waiting for doesn''t get there after 5 seconds (say) then ask the sender to send it again. You can also try to work around these issues at the protocol level (e.g. sending redundent data).
I recommend searching the web / looking at books for "sliding-window" protocols.
-Mike
Author
Thanks, I had a similar idea, but a sliding windows looks like a better approach. Do you know what the maximum UDP packet size is?
I have 1,5 years expierence of multiplayer server development. My opinion, advantage of UDP protocol for Web-oriented multiplayers games is myth. Practice is not the same. Since not all connections are ideal, UDP packets are losing. Both server and client must send agreement for recieved data to other side. Sometimes it''ll be happened without transfer any real game information. So on, your program must execute for UDP packets some TCP functions and some additional traffic.
I selected another way, one is to improve algorythm for TCP exchange. It works and really decreased traffic wihout any uncontrollable events. I think, it''s time to sell license,hah? But it''s needed to complete testing for re-establishment connection for played game.:-)
I selected another way, one is to improve algorythm for TCP exchange. It works and really decreased traffic wihout any uncontrollable events. I think, it''s time to sell license,hah? But it''s needed to complete testing for re-establishment connection for played game.:-)
Whether or not UDP is an advantage to you depends on your protocol. If you design your protocol so that it doesn''t matter if a few packets get dropped or reordered then you can win because TCP will go to great lengths to get all that stuff straight even though you don''t care. It is true that end up duplicating some of the functionality of TCP to get vaguely reliable transfers, you just don''t need all of it.
The common example is position updates. Consider if you send a position update that says you''re at pos1 and then another that says you''re at pos2. If pos1 gets dropped but pos2 goes through then you have the most recent data and the stuff in the dropped packet is irreleveant.
In theory a UDP packet can go up to ~64k in size but in practice the number that people quote is 1472 bytes of data. Larger packets will get fragmented by ethernet.
-Mike
The common example is position updates. Consider if you send a position update that says you''re at pos1 and then another that says you''re at pos2. If pos1 gets dropped but pos2 goes through then you have the most recent data and the stuff in the dropped packet is irreleveant.
In theory a UDP packet can go up to ~64k in size but in practice the number that people quote is 1472 bytes of data. Larger packets will get fragmented by ethernet.
-Mike
1472 bytes? what exactly does that figure mean? a packet of information for one player or for all players? i know it''s probably a stupid question, but what''s on my mind right now when i was asking that is, is that when the client sends its info to the server or when the server sends info about other players to a client? if my thinking is all screwed up, can someone clarify how this works for me? thanks.
a2k
a2k
That means when you call send() or whatever api you use to use send data the length of your buffer is no more than 1472 bytes.
Has nothing to do with clients or servers. It''s just the maximum amount of data you send at any one time - whoever the receiver might be.
When a server sends information to multiple players most of the time it''s going to do it by sending the same information to each player individually. Maybe I don''t understand that part of your question...
Has nothing to do with clients or servers. It''s just the maximum amount of data you send at any one time - whoever the receiver might be.
When a server sends information to multiple players most of the time it''s going to do it by sending the same information to each player individually. Maybe I don''t understand that part of your question...
i guess, i kind of mean, in that 1472 bytes, is that storage of information about 1 player normally? or what? or is other information usually stored in there, like maybe, also world information? i dunno... i guess, i was also thinking, the size of the packet also has an effect on the speed of the game, any help to get me to understand would be appreciated, thanks.
a2k
a2k
The minimum packet size that all IP segments must support is 576 bytes including headers (I think that''s the exact number, dont have the documentation right now). That means that if you want to eliminate IP fragmentation on the internet, you should keep your packets smaller than that size. The reason that staying below 1472 bytes is not enough is because most WAN (Wide Area Network) providers tend to use other technologies than ethernet in their networks.
Note, your packets may still be fragmented if for instance they are transported over an ATM netowork that tunnels the IP traffic, fragmenting each IP packet into 53 byte ATM packets, but you will eliminate IP-level fragmentation by staying below 576 bytes.
The main reason that UDP is often considered preferrable to TCP when it comes to gaming seems to be that TCP can take very long (read that it can take over a minute) to recover from packet loss, something that is unacceptable for many games. TCP was also designed to ''play nice'' with other protocols on the internet, sacrificing efficiency in order to share bandwidth better and avoid congestation. This makes TCP very attractive for many general networking applications but less so for games that really require effiency.
Henry
Note, your packets may still be fragmented if for instance they are transported over an ATM netowork that tunnels the IP traffic, fragmenting each IP packet into 53 byte ATM packets, but you will eliminate IP-level fragmentation by staying below 576 bytes.
The main reason that UDP is often considered preferrable to TCP when it comes to gaming seems to be that TCP can take very long (read that it can take over a minute) to recover from packet loss, something that is unacceptable for many games. TCP was also designed to ''play nice'' with other protocols on the internet, sacrificing efficiency in order to share bandwidth better and avoid congestation. This makes TCP very attractive for many general networking applications but less so for games that really require effiency.
Henry
Hm.. I tested UDP packets for very slow connection. It was mirroring of client sended data to client form server, including server time answer. Client was situated in Russian Federation, server in Germany (2Mb/sec).Time delays of this cycles was from 1 to 10 secs. Losed part of UDP packets was depended from size packet (from 20% to 90%).
I know, It''s very hard testing:-). But about good connections and big multiplayer systems. In this case difference in time between UDP and TCP is compatible with time of server handling of packets. And less... At other hand, games are not chats. I must provide correct order of moves. And using of UDP must be provided some additional server handling and time.
I know, It''s very hard testing:-). But about good connections and big multiplayer systems. In this case difference in time between UDP and TCP is compatible with time of server handling of packets. And less... At other hand, games are not chats. I must provide correct order of moves. And using of UDP must be provided some additional server handling and time.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
