Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


how much faster si udp


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
19 replies to this topic

#1 Mr.L   Members   -  Reputation: 125

Like
0Likes
Like

Posted 27 March 2012 - 05:28 AM

I've sometimes wondered how much faster than TCP is UDP, and go about what percentage it lost.

Sponsor:

#2 Madhed   Crossbones+   -  Reputation: 3074

Like
1Likes
Like

Posted 27 March 2012 - 06:45 AM

You can't really compare them like that.
UDP is a very very basic protocol that enforces nothing but intact packets. TCP in comparison is a beast of a protocol. It implements a lot of integrity rules that you may not need for the situation at hand.

Use UDP if you need low latency, TCP if you need steady throughput.

#3 Olof Hedman   Crossbones+   -  Reputation: 2901

Like
0Likes
Like

Posted 27 March 2012 - 07:30 AM

Also remember there is no guarantee a UDP packet arrives at the other end at all, or in any specific order.
TCP will automatically resend packages if needed, and make sure they are delivered in order to the application

So you must make sure the protocol you implement on top of it has no problem with lost packages and doesn't care about package order.

#4 frob   Moderators   -  Reputation: 22222

Like
0Likes
Like

Posted 27 March 2012 - 08:30 AM

When you have a good connection through the Internet their performance will be essentially equal; packets will arrive in order and on time, and both protocols have minimal overhead.

That describes almost all the time on the Internet. It is mostly very stable. In the general case of uncongested lines and stable hardware there will be no significant difference in performance.



The rare problems come when there is congestion, routing changes, or hardware failures along the line (which are not very often). In that case you need to handle the situation correctly; TCP handles all that for you in a very robust way. UDP assumes you know what you are doing and will handle it correctly by yourself. Can you handle it yourself, with performance better than TCP? That is a harder question.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#5 Olof Hedman   Crossbones+   -  Reputation: 2901

Like
0Likes
Like

Posted 27 March 2012 - 08:42 AM

That describes almost all the time on the Internet. It is mostly very stable.


Really?
Granted I don't have a lot of networking experience, and most of it a 7-8 years ago, my experience is the opposite.
Specially if you mix some wireless into it, which is pretty much the normal case nowadays.

One of the "bottlenecks" of TCP is the window size, it will only send a certain amount of packages before making sure the first one has arrived.
This will limit the speed when you have high latency.
Also, it eats some of the bandwidth in the "other direction", sending ACK packages, this could be nice to avoid if you have to handle a lot of traffic.

UDP is great if your protocol has no need of packages being in perfect order or lost, if you do need that, TCP is the better choice.

#6 frob   Moderators   -  Reputation: 22222

Like
2Likes
Like

Posted 27 March 2012 - 09:17 AM


That describes almost all the time on the Internet. It is mostly very stable.

Really?
Granted I don't have a lot of networking experience, and most of it a 7-8 years ago, my experience is the opposite.
Specially if you mix some wireless into it, which is pretty much the normal case nowadays.

Congestion and saturation are the major causes of lost packets. If you saturate your line you are more likely to lose packets. If you are flooding your line it doesn't matter if you are on wired or wireless connections, once it gets saturated it won't take any more.

One of the "bottlenecks" of TCP is the window size, it will only send a certain amount of packages before making sure the first one has arrived.
This will limit the speed when you have high latency.

Window sizes are negotiated at protocol start and are dynamically resized up to 1GB windows; that is part of the protocol. In practice this is rarely an issue.

Also, it eats some of the bandwidth in the "other direction", sending ACK packages, this could be nice to avoid if you have to handle a lot of traffic.

Traffic needs are asymmetric, and ack commands are very small. If you implement your own control system with UDP you will still need to implement something similar.

UDP is great if your protocol has no need of packages being in perfect order or lost, if you do need that, TCP is the better choice.

Some people have other needs. Many networking packages for games implement their own TCP-style layer on top of UDP where they can mix reliable information (such as game state) with unreliable information (such as delta-updates). If you have the means to do such a thing you can get slightly better performance than raw TCP in the general case along with all its benefits.

That type of solution is generally outside the reach of most beginners.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#7 hplus0603   Moderators   -  Reputation: 5518

Like
0Likes
Like

Posted 27 March 2012 - 10:18 AM

I've sometimes wondered how much faster than TCP is UDP, and go about what percentage it lost.


If there is no packet loss, then TCP and UDP are exactly the same speed.
If there is packet loss, then UDP gives you nothing (so, infinitely slow) whereas TCP will delay and retry until the data gets through (so, slower than immediate.)
You use UDP when you'd rather have no data than slow data. You use TCP when you'd rather have all the data, in order.
enum Bool { True, False, FileNotFound };

#8 Mr.L   Members   -  Reputation: 125

Like
0Likes
Like

Posted 27 March 2012 - 11:16 AM

so you mean for a little network game I could also easily accept TCP?

#9 zoneweb   Members   -  Reputation: 92

Like
0Likes
Like

Posted 27 March 2012 - 12:36 PM

If there is no packet loss, then TCP and UDP are exactly the same speed.


Even if there's no packet loss, TCP requires the receiver to send acknowledgements of received data.

#10 hplus0603   Moderators   -  Reputation: 5518

Like
0Likes
Like

Posted 27 March 2012 - 12:46 PM


If there is no packet loss, then TCP and UDP are exactly the same speed.


Even if there's no packet loss, TCP requires the receiver to send acknowledgements of received data.


That does not affect the speed of data transfer. In the distance past, long-distance transfers would slow down because of window exhaustion, but with window scaling that hasn't been a problem for a long time.
enum Bool { True, False, FileNotFound };

#11 Net Gnome   Members   -  Reputation: 773

Like
0Likes
Like

Posted 27 March 2012 - 02:41 PM

TCP is always slower than UDP because TCP has more overhead (ACK/NACK, etc.) in that it requires all packets to reach destination -in order-. UDP is basically fire-n-forget, while TCP is best-attempt. This is why real-time media uses UDP where not all of the packets have to be recieved to continue whereas TCP requires all data to reach its destination and is used when packet-x must reach the destination before packet-y to continue. With UDP you can accept the loss or implement an ACK/NACK stack of your own (usually you can get more efficient than TCP, since its AIMD - Additive incline, multiplicative decline).

#12 BeerNutts   Crossbones+   -  Reputation: 2978

Like
0Likes
Like

Posted 27 March 2012 - 02:47 PM

so you mean for a little network game I could also easily accept TCP?


Unless you really know what you are doing, I would suggest using TCP/IP for your little networked game to guarantee all your data arrives in the right order.
My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

#13 DvDmanDT   GDNet+   -  Reputation: 934

Like
0Likes
Like

Posted 27 March 2012 - 05:56 PM

Also remember that there are plenty of libraries out there, such as the Lidgren Networking Library if you are using C# or some other .NET language. Such libraries are often much easier to use and tends to implement reliable UDP. I preferr reliable UDP to TCP mostly due to the concept of packages instead of streams. If you use such a library, you can also get some nice features such as data channels which may reduce slowdown caused by packetloss since not all data needs to wait for a single package etc.

#14 hplus0603   Moderators   -  Reputation: 5518

Like
0Likes
Like

Posted 27 March 2012 - 07:23 PM

TCP is always slower than UDP because TCP has more overhead (ACK/NACK, etc.)


The point I made was that this statement, while often made, is simply not true most of the time. It is certainly not true if there is no packet loss.

No packet loss by implication means that the amount you need to send is less than the maximum capacity of the channel (this is necessary but not sufficient to make no packet loss,) which in turn is a necessary condition for any networked real-time game.


The size difference between TCP and UDP headers also often get swallowed in the packetizing of the underlying protocol (ATM or similar.)
You also erroneously state that TCP contains NACK packets. There are no NACKs in TCP.
enum Bool { True, False, FileNotFound };

#15 DvDmanDT   GDNet+   -  Reputation: 934

Like
0Likes
Like

Posted 27 March 2012 - 08:25 PM

One thing you should note if using TCP is the NAGLE algorithm or whatever it's called. It's an algorithm that tries to increase throughput by decreasing protocol overhead, which it does by sending as much as possible in every package. In other words, it holds of sending your data until it has X or more bytes to send, or until Y ms has passed. This makes it more efficient when sending larger amounts of data such as maps/saves etc, but can increase latency while sending small amounts of data such as player positions.

You can easily disable this algorithm though, just google TCP_NODELAY.

#16 Net Gnome   Members   -  Reputation: 773

Like
0Likes
Like

Posted 28 March 2012 - 03:35 AM


TCP is always slower than UDP because TCP has more overhead (ACK/NACK, etc.)


The point I made was that this statement, while often made, is simply not true most of the time. It is certainly not true if there is no packet loss.

No packet loss by implication means that the amount you need to send is less than the maximum capacity of the channel (this is necessary but not sufficient to make no packet loss,) which in turn is a necessary condition for any networked real-time game.


The size difference between TCP and UDP headers also often get swallowed in the packetizing of the underlying protocol (ATM or similar.)
You also erroneously state that TCP contains NACK packets. There are no NACKs in TCP.


RFC (3.7. Data Communication). my apologizes, they're not NACKs, but packets classified UNA. But no network is ever pristine, and should never be designed around those considerations. The reason UDP is faster, is that it doesn't care about this type of information at all, i.e., it just uses IP as the protocol, and thus has almost no overhead (RFC) since there are no acknowledgements, window syncs, etc., i.e., nothing to cause a hold-up.

Anyway, I'm not saying UDP is better than TCP (it isnt), its just not correct to say TCP is as-fast as UDP, since UDP will always put more data packets downstream faster than TCP, it just wont do anything more than that.

#17 samoth   Crossbones+   -  Reputation: 4913

Like
1Likes
Like

Posted 28 March 2012 - 05:53 AM

Anyway, I'm not saying UDP is better than TCP (it isnt), its just not correct to say TCP is as-fast as UDP, since UDP will always put more data packets downstream faster than TCP, it just wont do anything more than that.

While this is technically correct, it is mostly irrelevant, as hplus0603 pointed out. Many underlying "wire" protocols will hide this fact.

For example, ATM always transmits 53 byte cells (of which 48 bytes are payload). Whether you have 1, 5, 20, 40, or 48 bytes to send is exactly the same. Ethernet has a minimum payload of 48 bytes, and a mimimum interframe gap of 96 bits, whether you send zero or 48 bytes is exactly the same. The next frame cannot possibly be sent any earlier than a given minimum time (in case no one else uses the wire at that time, in which case your card will back off). Therefore, it does not really matter whether the header is a little bigger or not. Besides, TCP/IPv6 has header compression defined, in a similar manner to how PPP did it two decades earlier. I'm not aware that UDP/IPv6 does a similar thing. Header compression is a quite substantial saving -- so following your logic, TCP might actually be faster.

Being able to submit packets faster doesn't matter either, on many underlying wire protocols (take FDDI or TokenRing as examples). If you don't have a token, you're going to wait, end of story. It doesn't matter how fast you can send, you won't.

The necessity of ACK also means, technically, that TCP must be slower. In practice, ACKs often go piggyback or several are collapsed into one. So you end up having a few extra packets during a longer transmission, which really makes no difference. There are some odd packets on the wire all the time, from people scanning random ports on random IP addresses to ARP requests and other "secret stuff" that happens without you knowing or having to worry. They normally don't impact performance in any way. If you run Wireshark on your computer, you'll be surprised how many packets are sent and received when "nothing" happens.
Also, if you want to transmit a larger contiguous amount of data with UDP, you will need to acknowledge in some way, too. I can't seem to figure how you would do otherwise.

The only reason why I would agree on "TCP is slower" other than by irrelevant sophistries is the fact that data is guaranteed to arrive as an in-order stream. This may require your network stack to wait on data in some conditions. However, as pointed out by others earlier, these conditions are rare.
And, if they do occur, TCP is not necessarily any better either. It may in fact be worse. When a router is with its back to the wall, it will simply drop any packets that come in, until it can handle more. That means, it will drop TCP's packets just the same as it will drop UDP's packets.
With one notable difference... due to UDP being used for "live, hard realtime" stuff like telephony or video, many routers are configured to drop TCP first.

#18 Mr.L   Members   -  Reputation: 125

Like
0Likes
Like

Posted 28 March 2012 - 10:17 AM

okay so i keep using TCP.
Thanks

#19 turch   Members   -  Reputation: 590

Like
0Likes
Like

Posted 28 March 2012 - 10:53 AM

If you run Wireshark on your computer, you'll be surprised how many packets are sent and received when "nothing" happens.


Recently did that on a company LAN with ~100 salespeoples' computers, many of which have dropbox installed. Holy crap Posted Image

#20 hplus0603   Moderators   -  Reputation: 5518

Like
0Likes
Like

Posted 28 March 2012 - 03:17 PM

its just not correct to say TCP is as-fast as UDP


But nobody has said that. What we've said is that, absent packet loss, TCP and UDP are the same speed.
The "overhead" you talk about doesn't matter, for two reasons I already mentioned:
1) for a game to work at all, you must be sending less data than the max capacity of the channel, and therefore the overhead disappears in the noise
2) because of the way networks are actually physically implemented, packet sizes are usually quantized in such a way that the same data through TCP and UDP will actually use the same amount of physical network bandwidth

The behavior under packet loss is different between the two protocols, which is to be expected. However, the question was about "speed," not "behavior under loss."
enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS