how much faster si udp
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).
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.
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.
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.
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.
You can easily disable this algorithm though, just google TCP_NODELAY.
[quote name='Net Gnome' timestamp='1332880906' post='4925805']
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.
[/quote]
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.
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.
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
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."
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
