So, are you saying that UDP is faster than TCP Tyche? :evil:

UDP is a good choice for ephemeral data. IE: If you aren't going to mind occasionally losing something, or having things show up in the wrong order. Lots of games make use of UDP for status updates on the client side. If you miss one, no big deal… you'll get the next one and even if you miss a couple, all it does is make characters move a bit less smoothly. OTOH, players would get annoyed if the pushed the fire button and that packet got lost.

So, it depends what you're using it for. Typically, the client side of things will often attempt to calculate what will happen next and pre-render that, making corrections when the server sends positional updates. That's why you see characters seeming to jump and "teleport" around you when you're running with a group on a laggy connection. The client calculated their vector and drew them there, and then an update said they were actually 10 feet over because you missed the packet where they changed their vector of movement.

I have no idea what a text mud would use UDP to accomplish, though.

Some p2p clients use UDP for file transfer, as they can verify subsections of a file using a hash tree. I assume MMO clients check the integrity of data as well.

I am sorry, but those links do not address at all what I said. For example, the first one claims that UDP is faster because it doesn't do error correction – and therefore data is always flowing, if only partially. But I explicitly addressed this specific point. The second link I also explicitly addressed: there's no reason for the ACK packets to slow you down if the roundtrip packets keep flowing.

I didn't bother trudging through the rest, since the first two already failed to address the points I raised. (Exception: one of the links makes the silly claim that the packet size overhead will make things "much faster" on a per-packet basis – another issue I already addressed in this thread.)

Error-tolerant does not mean "faster" if the network is able to reliably provide error-free transmission anymore.

Anyhow, if UDP is so obviously faster, surely there is some data that you can provide that demonstrates rather than simply claims that all these things slow down TCP enough to be noticeable. All the links you gave, at least as you presented them, are merely unsubstantiated claims, not data or demonstration.

Additionally, many of your own citations make very important caveats regarding exactly when UDP is faster (namely in the face of errors).

So far, nothing you provided has shown that UDP is necessarily faster than TCP.

Just to forestall the obvious and make some additional notes, I am not saying, and never said, that TCP is always as fast as UDP. A UDP packet doesn't somehow make it across faster than a TCP packet, which is what I initially said anyhow in post #12. We both agree on this, as per your post #19. UDP will be "faster" if there is packet loss, however "faster" also can mean "lossy".

In other words it's hard to even compare the two because you gain speed and sacrifice correctness. A more appropriate comparison would be to use a perfect loss-less channel, and then compare the speed. In this case, TCP's requiring more packets can slow it down if the network doesn't have the bandwidth to support those extra packets.

Note that throughput and speed are not the same. Obviously, if you are flooding the above-mentioned perfect channel with as much as you possibly can, you will have higher throughput if you are sending data rather than acknowledgments.

If you're only sending a few packets, like a MUD might, then throughput is irrelevant. Perhaps latency becomes much more relevant, and then, if there is no loss, the data packets will arrive just as fast, as you agreed. And if the roundtrip occurs fast enough (depending on the network) then the server will be able to keep sending stuff without having to wait for ACKs. The ACKs are only an issue if you miss enough that you have to stop sending while waiting for ACKs. If TCP can continuously send when it wants to, then it's hard to argue that there is any slow-down!

So if this conversation is to continue meaningfully it should be clearly defined what exactly is being measured and under what circumstances. I used the word 'necessarily' very deliberately in #20.

Argument over.

Yeah, unfortunately I don't have the patience or time to add a the hundred or so more links to support my statement, and then argue about who said what for a hundred posts.

Hmm, let's see if I can speak your language correctly:
-1 grumpy failure to read post #25

At least we agree that our argument is over, although perhaps for entirely different reasons.

For anybody else reading this thread, I would urge you to understand the different meanings of "speed", such as throughput vs. latency, and to understand how these fit into any comparison of UDP and TCP. I also urge you to not stop at simplistic, over-generalizing claims that do not take into consideration (a) the environment being operated in and (b) the data you care about sending.

UDP has a header size of 8 bytes, TCP has a header size of 20-60 bytes.

Regardless of anything else, TCP will always take at least 12 more bytes to send data with, which will take longer.

Assuming a 56 kbit/s transmission device (yeah…), meaning 56kbit/s*1024bit/kbit=57344 bit/s, 12 bytes is 12*8 = 96 bits. So the header will consume 96/57344 or 0.001s on rather old transmission devices. Even Tyche – in his slew of links and before that as well – wasn't trying to argue that it was the header size that we actually care about. His main arguments have to do with extra packets being sent (the ACKs) and the error problems. As I said in #25, UDP absolutely is "faster" (but less correct) than TCP when there is packet loss. And, if the ACKs don't make it back to the server in time, then absolutely, TCP will stop sending until it gets the ACKs it wants. So there are absolutely certain circumstances where UDP is faster (and even some where it is faster while still being correct, if there is zero packet loss).

doesn't sound right.

UDP will /ALWAYS/ be faster than TCP
TCP will /ALWAYS/ be more reliable than UDP

Can somebody please explain to me exactly why it is that people find it remotely useful or even respectful to make claims without giving any justification whatsoever?

I wrote a whole post, several even, explaining why I believe that what you wrote is wrong or at the least misleading: was there some specific point(s) you disagreed with?

You guys are arguing a moot point. TCP and UDP are different protocols for different uses. It's stupid to even try to compare them for the same use. That's like saying which screwdriver will work best, a phillips or a flat? Well, which kind of screw are you using?

TCP is useful for situations where you want a stable connection that guarentees in-order packet delivery.
UDP is useful for situations where you want to send packets of interest, which may be safely lost or ignored on occasion.

Apples. Oranges. Both fruit, not the same.

That's why I said before, I don't see why a MUD would want to use UDP, as there is very little ephemeral data which isn't important to the experience. In a graphical game, missing a positional update isn't critical, you'll jitter a bit when you correct for the next one. In a text game, that'd be totally skipping a room description, which is somewhat less than optimal.

So, I'd like someone to explain why comparing the speeds of these two things is even remotely useful. :)

They're trying to find new and innovative ways to speed up their text based adventure for people with 9.6k modems.

Because it's fun winding you up, David. :thinking:

I think this is the real answer.. :P

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.

Please define what you mean by 'speed'; then perhaps we can have a meaningful discussion.

I would assume that the time it takes an object to get from point A to point B in this case.

As is my understanding (which is limited, only just really started delving into this stuff) UDP is faster because of a lack of implicit hand-shaking in regards to guaranteeing reliability, etc.

Having said that, I cannot see a reason, in my noobish state where UDP would be of benefit to a MUD. (Maybe if you had a custom client with some graphical interfaces that didn't really impact on the actual MUD. Even then, that's probably a big maybe.)

It depends on what you're doing. For some applications, UDP will let you get more data across in a shorter amount of time. Does this mean that it is always and necessarily faster no matter what you're doing? No…

Even then, as I have said several times now, there are many definitions of 'speed': do you mean throughput or latency? Do you mean instantaneous speed, peak speed, or average speed? Etc.



Well let me turn the question around and ask you why it is that UDP will always be faster? What circumstances are it that make it faster? I already discussed some. For example, in post 25,

If you consider maximum throughput to be your metric of speed, then UDP is using the channel for just data, not acknowledgments as well.

The whole question of lossiness is another one entirely.

TCP has the property that it only sends so much before it stops and waits for ACKs to come back. Let's assume that it only sends out 10 packets before waiting for an ACK on the first one, and acknowledgments take 10 seconds to arrive. Let's further assume that it can send out one packet per second, and that packets take a second to arrive. In this case, you see that the other end receives the first packet at time t=10, and by the time its ACK gets back it is t=11. Therefore, as our end sends out one packet at each of times t=0, 1, 2, 3, 4, 5, 6, 7, 8, 9, and doesn't send anything at time t=10 because it didn't get the ACK back. UDP would have happily continued sending, and therefore got more data across.

But let's assume that the acknowledgments get back more quickly, or that it sends out 20 packets before waiting for an ACK. In this event, it has a window of unacknowledged packets at any point in time, but this window is always smaller than the amount of packets before it actually stalls.

In other words: if you are in circumstances such that TCP stalls, it will be slower. UDP never stalls, although as a result data can be lost if the channel is unreliable.



There was some mumbling at some point about the appropriateness of trolling, or so I thought.



That's one definition of speed, however in my reply to Kiasyn I explained that the difference in the two using a 56kbps modem is a millisecond. But as Tyche said earlier,

In other words the packet size difference is immaterial: the far more interesting properties arise due to stalling and throughput.


Well, the TCP handshake isn't explicit, but yes, there is one, and yes, UDP doesn't have one. This is a one-time cost that is only a few packets, though.


There are very few reasons why you would. The argument was made initially that you might use UDP because it's "faster". My argument is simply that no, UDP is not "faster" in this instance (and as a corollary, UDP is not necessarily always faster). There are obviously all the other problems due to reliability: you wouldn't want a paragraph of text to vanish because the packet got lost.