TCP/IP vs. UDP (sort of one sided, but I promised this thread)
Author
Here''s the situation. You have a game that you need networked. It will be a fairly high speed, 2D space shooter. There will be a central server for a lobby, and the game needs to be networked.
The program parameters are as follows. All shots travel in a straight line after being fired. Player cannot stop on a dime, so normal physics of motion apply. World coordinates are measured with FP numbers, using X and Y planes only. Z plane is not used. Players must be allowed to join or leave the game at any time. Should be scalable to dozens of players. It is meant to be played over the internet, so internet latencies and lag apply.
What is the best way to do it? The lobby server is a required component to find the game, so that can''t be cut out. Continued communication with the lobby server is not required, but it must know when people enter and leave the game.
Post your questions about the problem and possible solutions with pros and cons here. You should also comment on how the game should handle dropped packets, dead reckoning, latencies, etc, distorting the game as little as possible.
Discuss and be happy. Otherwise, continue the flame war from that *other* thread.
Looking for an honest video game publisher? Visit www.gamethoughts.com
it''s simple...
TCP ip send message and wait for a response to be sure that the message is receive... so with TCP:
time = 0
PC1 send message to PC2 : time += T
PC2 respond to PC1: time += T
with TCP the time is 2*T to send a message
with UDP no response is wait so the time is T but you''re not sur that the message is receive...
conclusion: choose the adapted protocol for your game
lol
TCP ip send message and wait for a response to be sure that the message is receive... so with TCP:
time = 0
PC1 send message to PC2 : time += T
PC2 respond to PC1: time += T
with TCP the time is 2*T to send a message
with UDP no response is wait so the time is T but you''re not sur that the message is receive...
conclusion: choose the adapted protocol for your game
lol
That is a highly flawed explanation of the time TCP takes to send a message, and is quite far from correct.
Firstly, aside from, the more technical aspects, for a single packet, it takes (near enough to) the same time for the packet to get from one end to the other no matter wether you''re using udp or tcp. It''s just data when you get to that level. One end of the conenction can use a message received via TCP as soon as it has arrived, exactly the same as with UDP (not taking into account fragmentation etc.), it doesn''t have to wait until the sender receives an ACK before it can use it. Data takes the same time to get from end to end no matter what the above protocol is.
TCP''s latencies come from various sources.
1) Sliding window protocol. This is the closest to what you are talking about, but the result is rarely equivalent to twice the time required to send a packet one way. Sliding window throttles a connection so that the other end can define how much data is being sent to it. In a best-case scenario, the sliding window will never reach a size of zero, always receiving enough ACKs to keep expanding the window at least as fast as it can send data (empty the window). In this case TCP is just as "fast" as UDP. However, due to the unreliability of the internet, the sliding window usually reaches a size of 0 quite often, due to dropped packets (packets with errors), or network congestion (packets dropped at routers). In this case, TCP can be much "slower" because it must re-send packets and/or wait a long time between sending packets.
2) The slow start algorithm. This occurs when the network is congested and traffic is passing very slowly. I can''t remember the exact trigger for this to occur, but it is due to congestion.
Effectively, when slow-start is engaged, the max. size of the sliding window is reduced to 1, and is then doubled each time it receives an ACK until it is at full capacity again. This is killer on games etc. because a connections speed will suddenly die for (2*latency) and slowly speed up again, even if network congestion was not bad enough to warrant dropping that far.
There are other ways TCP can be "slower" such as the nagle algorithm, which buffers data in the OS for a short time, rather than sending immediately (this is to reduce the ratio of TCP header to actual data).
I think when people new to TCP and UDP see talk of UDP being faster they may get the wrong idea. Data sent with the UDP protocol is not transmitted faster, but on an unreliable link (such as the internet) UDP will impose less delay on the message being sent than TCP will.
Firstly, aside from, the more technical aspects, for a single packet, it takes (near enough to) the same time for the packet to get from one end to the other no matter wether you''re using udp or tcp. It''s just data when you get to that level. One end of the conenction can use a message received via TCP as soon as it has arrived, exactly the same as with UDP (not taking into account fragmentation etc.), it doesn''t have to wait until the sender receives an ACK before it can use it. Data takes the same time to get from end to end no matter what the above protocol is.
TCP''s latencies come from various sources.
1) Sliding window protocol. This is the closest to what you are talking about, but the result is rarely equivalent to twice the time required to send a packet one way. Sliding window throttles a connection so that the other end can define how much data is being sent to it. In a best-case scenario, the sliding window will never reach a size of zero, always receiving enough ACKs to keep expanding the window at least as fast as it can send data (empty the window). In this case TCP is just as "fast" as UDP. However, due to the unreliability of the internet, the sliding window usually reaches a size of 0 quite often, due to dropped packets (packets with errors), or network congestion (packets dropped at routers). In this case, TCP can be much "slower" because it must re-send packets and/or wait a long time between sending packets.
2) The slow start algorithm. This occurs when the network is congested and traffic is passing very slowly. I can''t remember the exact trigger for this to occur, but it is due to congestion.
Effectively, when slow-start is engaged, the max. size of the sliding window is reduced to 1, and is then doubled each time it receives an ACK until it is at full capacity again. This is killer on games etc. because a connections speed will suddenly die for (2*latency) and slowly speed up again, even if network congestion was not bad enough to warrant dropping that far.
There are other ways TCP can be "slower" such as the nagle algorithm, which buffers data in the OS for a short time, rather than sending immediately (this is to reduce the ratio of TCP header to actual data).
I think when people new to TCP and UDP see talk of UDP being faster they may get the wrong idea. Data sent with the UDP protocol is not transmitted faster, but on an unreliable link (such as the internet) UDP will impose less delay on the message being sent than TCP will.
UDP is faster....
test by yourself.....
program a client UDP and TCP...and get the times
....
Blizzard =>...Starcraft/Broodwar...Warcraft....use UDP....so it''s better... that''s all...
test by yourself.....
program a client UDP and TCP...and get the times
....
Blizzard =>...Starcraft/Broodwar...Warcraft....use UDP....so it''s better... that''s all...
quote:Original post by Anonymous Poster
UDP is faster....
test by yourself.....
program a client UDP and TCP...and get the times
....
Blizzard =>...Starcraft/Broodwar...Warcraft....use UDP....so it''s better... that''s all...
Maybe you should clarify the Warcraft statement.
Warcraft 2 (non-Battle.NET version) used IPX. Would you say IPX is better?
But you can add Quake3 to your list of games. It supports UDP (and IPX, I think, but that''s a different issue).
As for the question, I would use TCP for the lobby code and then switch to UDP for the actual game.
I think I would shoot for sending packets at no more than 20fps (or another rate...adjust it in testing) and interpolating the results on the client. If you sent information about each player''s position (2 fp values), velocity (2 fp values), and acceleration (2 fp values) then it would be very easy to predict where everyone will be in the missing frames, and you would only need 24 bytes per player. Dozens of players would still only be in the hundreds of bytes. The same sort of data (position, velocity, acceleration) should be used for bullets/lasers/etc.
I know you could probably get away with position only, but if the server sends accurate data for the first and second derivatives, you can do the predictions with less calculations. Maybe even use a fourth derivative (which I suppose would be a positive constant if accelerating and a negative constant if braking...not sure what turning will do to this vector). This way you wouldn''t have to look at as many previous frames in order to get smooth motion.
You will also need some sort of a timestamp on the packets. If you receive a packet older than the most recent packet you''ve handled, then ignore it. If it is newer, then update the local values. Dropped packets shouldn''t be a problem as another packet will likely arrive shortly.
I''ve never actually used UDP so it''s pretty sketchy from here. I''ve read lots of theory on the matter but never sat down and used it.
Here''s a question I wanted to ask on that *other* thread. How would one go about programming IP directly (not UDP or TCP)? I''m not actually considering doing this, but I am just curious. Do the APIs let you send raw IP packets? If so on what operating systems? Is it an NT-only thing? etc.
I''m asking because I have used raw ethernet packets before for a class project. I wrote a program that sent a wake-on-LAN magic packet as a raw ethernet packet. I know that this is actually easier with TCP/IP, but my program was cool (to me anyway) because it did not require you to have any particular protocols installed.
Would programming IP directly be similar to programming at the Ethernet level? I know what information goes in an IP packet so I think I could do this myself if I needed. Then again, I would never do this, I am just curious.
--TheMuuj
Your argument is flawed, AP.
Stating that an API is better because your favorite games'' developer uses it is like stating that one graphical API is better than another because a particular developer uses it.
Instead, concentrate on the facts: TCP is a "guaranteed messaging" protocol (i.e. the packets will be received in the order in which they were sent). This makes things like physics, motion, and action-event updates a little easier to manage. UDP on the other hand, requires that the programmer manage this.
UDP packet transmission is certainly ''faster'' in general because of its smaller size and lack of error-compensation, but what advantage does this have if the developer implements his own protocol-layer (essentially mimicking TCP so that packets are sorted properly) that ends up slower than TCP?
mtaber: What are your target players'' connection speeds? I would presume maybe a 30/70 dialup/broadband ratio. In that case, you have about 5-6 kilobytes per second per client to play with. Events for ''change'' rather than ''update'' are likely what you want to send.
1) The basis for movement, velocities, positioning, rotations, should be on a time variable that is maintained by the server, and updated often so that the clients always have a proper notion of where objects in space should be. The more often this is sent, the more often gamers with slower computers won''t be confused when their ship blows up, then half a second later they see the ship that destroyed them.
2) Send packets for clients'' changes in acceleration, rotation, and so on, rather than sending each clients'' position 15-30 times per second. On each client, calculate positioning of each object based on time from #1.
3) The values from #2 could certainly be miscalculated slightly, so it''s probably necessary to update infrequently with "correction" positionings (the stuff from #2 that you don''t want to do 15-30 times per second). These packets don''t really need to be sent that often, but you should be able to increase their proliferation based on how much network latency there is.
4) Finally, ''major'' events (one-shot events that do not cause updates, such as explosions or ''game over'', etc) need to be guaranteed to be sent to the clients.
Good luck!
MatrixCubed
http://MatrixCubed.cjb.net
Stating that an API is better because your favorite games'' developer uses it is like stating that one graphical API is better than another because a particular developer uses it.
Instead, concentrate on the facts: TCP is a "guaranteed messaging" protocol (i.e. the packets will be received in the order in which they were sent). This makes things like physics, motion, and action-event updates a little easier to manage. UDP on the other hand, requires that the programmer manage this.
UDP packet transmission is certainly ''faster'' in general because of its smaller size and lack of error-compensation, but what advantage does this have if the developer implements his own protocol-layer (essentially mimicking TCP so that packets are sorted properly) that ends up slower than TCP?
mtaber: What are your target players'' connection speeds? I would presume maybe a 30/70 dialup/broadband ratio. In that case, you have about 5-6 kilobytes per second per client to play with. Events for ''change'' rather than ''update'' are likely what you want to send.
1) The basis for movement, velocities, positioning, rotations, should be on a time variable that is maintained by the server, and updated often so that the clients always have a proper notion of where objects in space should be. The more often this is sent, the more often gamers with slower computers won''t be confused when their ship blows up, then half a second later they see the ship that destroyed them.
2) Send packets for clients'' changes in acceleration, rotation, and so on, rather than sending each clients'' position 15-30 times per second. On each client, calculate positioning of each object based on time from #1.
3) The values from #2 could certainly be miscalculated slightly, so it''s probably necessary to update infrequently with "correction" positionings (the stuff from #2 that you don''t want to do 15-30 times per second). These packets don''t really need to be sent that often, but you should be able to increase their proliferation based on how much network latency there is.
4) Finally, ''major'' events (one-shot events that do not cause updates, such as explosions or ''game over'', etc) need to be guaranteed to be sent to the clients.
Good luck!
MatrixCubed
http://MatrixCubed.cjb.net
No no no and No !
it''s TCP vs UDP.i saied Warcraft... it''s Warcraft 2 and 3...i''m not stupid ok ?....
now !
why acceleration...interpolation...etc etc... just send the user commands... commande is: (unit Z goto X, Y) that''s all...others players know how to move the unit...
there is no interpolation or something like this...
it''s TCP vs UDP.i saied Warcraft... it''s Warcraft 2 and 3...i''m not stupid ok ?....
now !
why acceleration...interpolation...etc etc... just send the user commands... commande is: (unit Z goto X, Y) that''s all...others players know how to move the unit...
there is no interpolation or something like this...
I think a lot of people are missing the main point of UDP, it doesn't ensure ordering of packets. This means that you can still get new data if a packet is dropped - with TCP/IP you have to wait for what is now probably stale info before you can get on with new data.
Anyway, this is such old ground! I think most of us already know the answers.
As to the guy above who doesn't want to send differentials, knock yourself out bud, but your prediction is gonna look crap. Even with a RTS you might hit some nasty syncronisation issues with units taking different routes to a target. With a game where you have direct control of the entity (i.e. you are steering, not clicking on a spot to head to) you will have massive problems.
[edited by - DanH on July 17, 2002 12:13:16 PM]
Anyway, this is such old ground! I think most of us already know the answers.
As to the guy above who doesn't want to send differentials, knock yourself out bud, but your prediction is gonna look crap. Even with a RTS you might hit some nasty syncronisation issues with units taking different routes to a target. With a game where you have direct control of the entity (i.e. you are steering, not clicking on a spot to head to) you will have massive problems.
[edited by - DanH on July 17, 2002 12:13:16 PM]
quote:Original post by Anonymous Poster
No no no and No !
it's TCP vs UDP.i saied Warcraft... it's Warcraft 2 and 3...i'm not stupid ok ?....
now !
why acceleration...interpolation...etc etc... just send the user commands... commande is: (unit Z goto X, Y) that's all...others players know how to move the unit...
there is no interpolation or something like this...
WHAT? How does just sending the commands help reduce the effects of lag? And what if one client gets off?
If your screen is updating at 60fps and you are getting network packets at 15fps, all of the other players are going to look REALLY choppy.
Like I said, you should have clarified the WarCraft thing. I was JOKING but you seem to take me seriously. "Warcraft" (which is what you said) has NO network support. Warcraft 2 used direct connection or IPX. Warcraft 2 BNE added support for TCP (but I'm not sure about UDP). Warcraft 3 uses UDP.
And you use a lot of ellipses (...) in your writing. Any reason why? You are using (somewhat) complete thoughts, so why act like you have more to say in each sentence?
--TheMuuj
[edited by - themuuj on July 17, 2002 12:18:03 PM]
quote:Original post by TheMuuj
And you use a lot of ellipses (...) in your writing. Any reason why? You are using (somewhat) complete thoughts, so why act like you have more to say in each sentence?
hey man, leave the ellipses out of this... they have NOTHING to do with this issue...
--- krez (krezisback@aol.com)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
