Archived

This topic is now archived and is closed to further replies.

mtaber

TCP/IP vs. UDP (sort of one sided, but I promised this thread)

Recommended Posts

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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
Guest 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...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Guest 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...

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
quote:
Original post by krez
hey man, leave the ellipses out of this... they have NOTHING to do with this issue...
--- krez


I have nothing against ellipses, but a single period will suffice in most cases, will it not?

Anyway...

I just remembered something about the derivative of acceleration. I know you have velocity and acceleration, but I seem to remember someone once giving a name to the 3rd derivative of displacement. I personally like the term accelerocity, but is there any word that is the (de facto) correct term? If so I would definately use it in my programs (internally) when I have a variable for such things.

--TheMuuj

[edited by - themuuj on July 17, 2002 12:43:04 PM]

[edited by - themuuj on July 17, 2002 12:44:25 PM]

Share this post


Link to post
Share on other sites
Yes, assume that the ratio of modem/broadband is about 30/70.

As for AP, trust me, you can''t just send the position every frame and expect the other player to get it and display it correctly. Think about this. If I send it every single frame, then theoretically, the other players will see that every single frame. The problem is that what is currently displayed for them will be what I was doing and where I was at about 250ms ago. Doesn''t sound like a long time, but when you''re turning in a tight loop, it would matter. This is assuming that no packets are dropped.

Say you were chasing someone and firing at their rear. Some router decides to start dropping packets just as your shots get close to him. He pulls a tight loop to the right, and ends up behind you. Because of those dropped packets, you won''t even see that he turned. Suddently he''s behind you and firing at you. It will look like a major programming bug and it''s not.

Sending that many updates would simply not be feasible. Not to mention, that sending every single frame assumes that everyone has the same framerate. If you have a framerate of 240 fps and I have a framerate of 30fps, what you see is going to be very choppy. Based on the assumption that no packets are dropped and the packets arrive at the same time, every time, you will see me move every 8 frames of animation. It''s not going to look consistent. You absolutely must use some type of interpolation.

As for the derivatives, they are position, velocity and acceleration. Position is pretty much displacement, although I''m sure if you talk to someone with a PhD in Physics, he''d tell you they''re not the same thing and he''d be right. Let''s just call it position for now.

dx = derivative, dx^2 = the second derivative

dx(position) = velocity
dx^2(position) = dx(velocity) = acceleration

You don''t take the third or fourth derivative. To go from the acceleration function to the velocity or position, you take the integrals.

Integral(acceleration) = velocity + C where C is an unknown constant

Integral^2(acceleration) = Integral(velocity + C) = position




Looking for an honest video game publisher? Visit www.gamethoughts.com

Share this post


Link to post
Share on other sites
quote:
Original post by MatrixCubed
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?



Hi MatrixCubed. I have no idea why you say that TCP makes physics easier. Maybe you can go into further detail? Since TCP is streamed, and has inherent latencies, you are likely to get updates in a less timely manner. This results in frustrating play for the end users.

Anyone who has ever implemented a game using a "reliable" UDP will tell you that you do NOT end up with something that is slower than TCP (unless your pet monkey writes your code). First of all, you don't mimic TCP. Typically, you only provide reliability and order. There is far more to TCP than reliability and order. Flow control, full-duplex connection, TIME_WAIT, congestion avoidance and so on... Those items introduce huge latencies and system overhead.

Many games that have nice physics engines use UDP... I'd be willing to say most games in general use UDP. I agree that just because company "A" used it for game "X" doesn't mean that it's the best for company "B" to use for game "Y". But there is probably a good reason that company "A" made the decision to use UDP in the first place.

It is reasonable that people think TCP is the obvious choice, because it does the work for you. But as you gain experience, particularly handling thousands of simultaneous users, you will see that the overhead of writing UDP-based networks is more than worth the rewards.

Edit: By the way, I checked out your website, it looks pretty cool. Be advised there is a commercial game in development called PlanetSide.


[edited by - fingh on July 17, 2002 3:18:06 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Also, on a semi-related note, it should be noted that you can turn Nagle''s algorithm off if you so desire, meaning that TCP will not wait and accumalate data before sending.

Share this post


Link to post
Share on other sites
quote:
Original post by TheMuuj
I just remembered something about the derivative of acceleration. I know you have velocity and acceleration, but I seem to remember someone once giving a name to the 3rd derivative of displacement. I personally like the term accelerocity, but is there any word that is the (de facto) correct term? If so I would definately use it in my programs (internally) when I have a variable for such things.


I just found the answer myself. Apparently the 3rd derivative of position is called 'jerk.'

And apparently there is such a device that can measure jerk, called a jerkmeter (boy I wish I had a jerkmeter when dealing with jerks!)

The name jerk actually makes a bit of sense when you start thinking about it. Like, when you are riding in a car, you feel the changes in acceleration more than anything. If a car changes from an acceleration of 1m/s^2 to -2m/s^2 in a single second, you will feel quite a jerk.

I have also come across a uses for jerk when doing cubic splines on motion, and it could certainly come into play when interpolating movement data.

The term 'jolt' seems to be used in the UK at times, but it makes me think of a drink with lots of caffene.

Now I will have to remember to use that term in my code. :-)

float timeDelta = 0.1
Vector3 jerk, acceleration, velocity, position;
...
position += velocity * timeDelta;
velocity += acceleration * timeDelta;
acceleration += jerk * timeDelta;

I like how that looks, even though I don't think I will ever use it like THAT. :-)

--TheMuuj

[edited by - themuuj on July 18, 2002 10:19:07 AM]

Share this post


Link to post
Share on other sites
jerk. That''s pretty funny. I don''t think I''ve ever heard it formally called that.

Then again, when I went to college, we were doing continuous functions of time. When you talk about the difference from one second to the next, that''s discrete time and that''s where the third derivative would apply. We used Z transforms for discrete differential equations. Mostly LaPlace transforms for continuous diff-eq''s. For Z transforms though, we never really discussed the formal names of them. My professors were more concerned that you understood the concepts well enough to be able to apply them to digital systems with analog interfaces to things like motors for control systems. I always thought it was pretty neat, but I hated the work. Even for ''simple'' problems, the solution was typically 3-4 pages long, and that''s because my handwriting was small. A lot of other people would have easily twice that.

As scary as this sounds, I can actually imagine using Simulink within Matlab to calculate what a smooth framerate would be in a 3D FPS game. If your program drops below that framerate, you should start dropping the level of detail of the scene to compensate so the game doesn''t become, shall I say, ''jerky''?

heh. I''m not going to go on. This could turn very stupid very quickly.


Looking for an honest video game publisher? Visit www.gamethoughts.com

Share this post


Link to post
Share on other sites
For this type of situation, I''d recommend using UDP. Packets arrive when they do, and not all of them may be necessary.

It should be a simple choice, large, fast paced games, where time is critical, UDP is a good choice, send things and hope they get there, resend the ones that are absolutely necessary if you didn''t get a reply.

TCP is fine for games too (especially the non time critical ones), you just have to know when to use it.

Tribes 2 used UDP, and this was pretty much the developers'' reasoning.

Share this post


Link to post
Share on other sites
A good network layer will use both because both have advantages over the other.

TCP is good for those messages that must be reliable; connect, disconnect, full state, chat, opening a door, using an object, etc. It makes sure the packets get there and it does it at the system level, a good advantage over UDP, especially on the server.

Advantages: System level reliability service. Bandwidth reduction for bad conections (sliding window and slow start). Easy to route through firewalls (very important for some customers, especially in Asia.)

Disadvantages: Nagle algorithm wait times, but this can be disabled on most IP stacks). Bandwidth reduction for bad connections (sliding window and slow start).


UDP is good for those messages that don''t have to get there; delta state mostly, but sometimes others like chat. Since clients can make up for losing this information, UDP will work and gives a few advantages over TCP. You can write your own reliabity service if you would like to replace TCP, but you should still support both.

Advantages: It has slightly less header overhead than TCP, which reduces bandwidth.

Disadvantages: Not all firewalls will route it. You must write your own reliability service if replacing TCP. First type of packet to be dropped by routers.


Did I forget any?

Anyway, what I''m trying to say is there is no one solution for everything. Evaluate what you need and use what is required.

For the original post, use UDP for everything. If you want to make sure chat gets through, use TCP for that. But the game is small so you don''t need it.


Stephen Manchester
Senior Technical Lead
Virtual Media Vision, Inc.
stephen@virtualmediavision.com
(310) 930-7349

Share this post


Link to post
Share on other sites
quote:
Original post by mtaber
You should also comment on how the game should handle dropped packets,


If you specific how it should handle dropped packets (other than *must* resend or disconnect), you can''t use TCP; the specification would then require a UDP (or lower) protocol.

Share this post


Link to post
Share on other sites
I''ve worked with three seperate net libraries with commercial MMOGs. Of the three, only one uses TCP. It is not currently used in any core game systems, only backend support services (e.g. administration, etc...).

The other two libraries provide reliable UDP services in addition to the standard ''best-effort'' UDP service. Once you have a well-tested reliable UDP system, you really don''t need to resort to TCP unless you are working with another external protocol like HTTP. TCP has some advantages over UDP (and vice-versa), as listed by other posters. But if you have a well-rounded network library, you can accomplish pretty much anything with UDP. An obvious exception is OOB data. Most NATs and firewalls can handle UDP with proper configuration. I believe some load balancing equipment works best with TCP, but I''m not positive.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Pro UDP
send the last second of the directx 9 user input buffer
repeat this every 50ms, so you have overlapp (security).
lag>1sec , even occasionally is to much, kill this player

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
lag>1sec , even occasionally is to much, kill this player


No it''s not. I used to play Asheron''s Call with ~1s lag. I live in Australia, and at the time, I only have a 56K connection. It was still playable, though rather laggy (but not detrementally so - sometimes I''d click on a monster, but someone had already killed it, etc).

If you work your game mechanics right, large amounts of lag shouldn''t be that big a deal.

If I had my way, I''d have all of you shot!


codeka.com - Just click it.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
>It will be a fairly high speed, 2D space shooter
Player will shoot each other,
so lag is worse here than when clicking on a monster

Share this post


Link to post
Share on other sites