24 Mar, 2010, Dean wrote in the 41st comment:
Votes: 0
@DH - Thanks for breaking down my post. As I said, I've only really started getting into the whole TCP/IP "stuff" in my network/systems admin course I'm doing at the moment and so far, I've learned a few things from this thread (after re-reading it) which is great.

But I digress and go back to lurking.

:blues:
24 Mar, 2010, David Haley wrote in the 42nd comment:
Votes: 0
I said:
Well, the TCP handshake isn't explicit

Oops! I meant to say: it's not implicit: there is an explicit handshake at the beginning of each connection. Sorry. :redface:
27 Mar, 2010, Tyche wrote in the 43rd comment:
Votes: 0
kiasyn said:
But my understanding is UDP will always be faster, not under certain circumstances. Can you explain to me why this is wrong?

I don't see how TCP can match speeds equal to UDP.


Indeed. Studies have shown that NFS over UDP is faster than NFS over TCP and that Corba over UDP is faster than Corba over TCP. Stevens has stated in TCP Illustrated that T/TCP can never be faster than UDP, because the overhead of the underlying TCP protocol. Anarchy Online which runs over TCP wrote a paper on how they achieved faster performance by rewriting (gutting congestion control features) the TCP stack. The burden of proof is really on the one making extraordinary claims, if they really are.
27 Mar, 2010, David Haley wrote in the 44th comment:
Votes: 0
It makes perfect sense that NFS be 'faster' because it is more interested in throughput. I don't know why you refuse to define what exactly you're talking about. There are many reasonable definitions of "speed". If your definition is that "speed" == "throughput", then I have never argued with that and have, in fact, said several times that UDP has higher throughput. Seems to me like it's more of a personal thing, really. You argue with me, call me incorrect and borderline stupid, and yet don't actually respond to what I say. :shrug: Oh well.
28 Mar, 2010, kiasyn wrote in the 45th comment:
Votes: 0
speed = how quickly it travels?
28 Mar, 2010, David Haley wrote in the 46th comment:
Votes: 0
That's a very reasonable definition of speed. If that's your definition, it is apparently not what some people have been arguing:
Tyche said:
but not because of the packet size nor because the packets somehow travel faster.

Indeed, the difference in packet size (due to the header) is so negligible on a modern device that you are extremely likely to notice it: indeed even on a relatively antiquated (by now) device like a 56kbps modem, the difference is only a millisecond. The math is easy to do to show that on a device like a 1Mbps cable modem, the difference is even more negligible.

Another very reasonable definition of "speed" is "the maximum amount of data you can send in a given time frame": this is basically throughput.

Other useful definitions of "speed" are things like latency, however latency is (typically) a property of the transmission method rather than the protocol and therefore isn't really a distinguishing factor between TCP and UDP. TCP does however have the interesting property that I have discussed (e.g., in reply to you, Kiasyn, in post 40, to some length) of being slowed down in case it doesn't get its ACK's back in time. (This is related to why it has smaller throughput.)

For instance, in some cases you might have a connection (like a satellite) that has very high latency but very high bandwidth. Other connections can have extremely high throughput but even higher latency (such as sending physical hard drives). For instance, if you have to move hundreds of terabytes of data, you are likely to care about the total time for the entirety of the data to arrive: this is very different from "how quickly it travels", because indeed it might be faster to ship the disks on a plane rather than use the network.

In the end of the day, this is a subtle issue, and that is why it is worth actually explaining, rather than making blanket statements that serve little educational purpose.
28 Mar, 2010, quixadhal wrote in the 47th comment:
Votes: 0
kiasyn said:
speed = how quickly it travels?

Actually when talking about data transfer, speed = how quickly it travels at a given rate of data loss.

TCP guarantees packet delivery, and will slow down transmission until the remote end acknowledges receipt. It also guarantees that packets will arrive in the order they were sent.

UDP makes no such claims. It sends packets. Packets arrive at the recipient, or they don't. They arrive in whatever order they arrive, which may vary if the network route changes during transmission.

So, if you're going to compare TCP vs. UDP in terms of speed, you have to define what an acceptable loss rate is, because UDP will NOT ensure all the data arrives. You can do your own link integrity checking and receipt verification with UDP, but that's up to you to design. Many games have done so, but they usually end up writing code that's very similar to what TCP already gives you… so unless you really need a connectionless transfer stream, or only generate burst traffic, or think you're better than the TCP authors at writing transfer verification logic… :)
28 Mar, 2010, David Haley wrote in the 48th comment:
Votes: 0
I've seen some interesting stuff with UDP where they only do partial receipt verification. The server sends out object position information (and vectors etc.) and the client needs to ACK back every few updates. This helps the server figure out who is actually getting the updates (and try to make sure those updates eventually make it) without completely stopping the updates in the event of not getting ACKs (which is what TCP would do). Also, they used a sequence number, so that people would know if the data they just received was rendered obsolete by data they already received.

quixadhal said:
TCP guarantees packet delivery, and will slow down transmission until the remote end acknowledges receipt.

Technically, it has a window of unacknowledged packets; it will only start slowing down transmission if the number of unacknowledged packets exceeds this window. Some people think that TCP sends a packet and waits for an ACK, but this is not the case in typical implementations (unless you have a silly-small window).
29 Mar, 2010, quixadhal wrote in the 49th comment:
Votes: 0
The default setting for every version of Windows from 2000 onward is one ACK for every two packets. Because it's a fixed window size, most gamers modify the registry to reply on EVERY packet to reduce latency.

Since windows machines comprise about 90% of all client machines in the world, I think it counts as the most popular implementation.

I agree that UDP can be quite useful, but not for the same things that TCP is designed to handle, and any speed comparison has to take the potential packet loss into account.
29 Mar, 2010, David Haley wrote in the 50th comment:
Votes: 0
quixadhal said:
Because it's a fixed window size, most gamers modify the registry to reply on EVERY packet to reduce latency.

I'm not convinced this would always work, because it's increasing traffic, but in some circumstances it probably would. A nice feature of TCP is that if you ACK packet n, you implicitly ACK packets 1,2,3,…,n-1 as well. (The contract is that you don't ACK a sequence number until you actually receive everything up until that number.)

That said this is the window on the receiver end, not the sender. The sender also has its own window for how many packets to leave un-ACK'ed before it sends out more.
29 Mar, 2010, quixadhal wrote in the 51st comment:
Votes: 0
Theory or no, making that registry change drops your response time in World of Warcraft from about 250ms to about 100ms. It also slows downloads, but that's expected since you are indeed sending more outbound traffic.
29 Mar, 2010, Tyche wrote in the 52nd comment:
Votes: 0
quixadhal said:
So, if you're going to compare TCP vs. UDP in terms of speed, you have to define what an acceptable loss rate is, because UDP will NOT ensure all the data arrives. You can do your own link integrity checking and receipt verification with UDP, but that's up to you to design. Many games have done so, but they usually end up writing code that's very similar to what TCP already gives you… so unless you really need a connectionless transfer stream, or only generate burst traffic, or think you're better than the TCP authors at writing transfer verification logic… :)


A specific implementation will be faster than a general purpose one. Something I attempted to illustrate by referencing several studies on different sorts of specific implementations.

I have noticed that many mud protocols are an attempt to bypass stream behavior and provide out of band date. So…

I've written a server/client UDP application that sends map data to the client. It's a FXRuby application that uses GD to draw a map from a data structure, and then later accepts position data to update the characters position on the map. It's independent of whatever client you are using…here's a screenshot using a MushClient. Obviously you could do the same with status bars, avatars, equipment displays, OLC editors, etc.

Just a note on this specific application: I generate dungeons on the fly, yet I don't have a dungeon movement system in place yet. So this implementation of the dungeon on the server is in terms of Rooms, Corridors, and Exits . Using the traditional movement system I just position my avatar (which is awfully out scale to the map) in the center of the Room or Corridor one is in and crop the image around it. The simple protocol has two channels, one for data that needs to be acknowledged and one for data that doesn't. In any case this model can be extended for any number of plugins or even dumping the TCP connection in favor of a plugin to do that. :-)
40.0/52