David Haley
Wizard
Group: Members
Posts: 6,874
Joined: Jun 30, 2007
|
#46 id:44604 Posted Mar 27, 2010, 10:25 pm
|
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.
|
|
|
quixadhal
Wizard
Group: Members
Posts: 1,472
Joined: Oct 17, 2007
|
#47 id:44638 Posted Mar 28, 2010, 10:47 am
|
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... :)
|
......................... 
|
|
David Haley
Wizard
Group: Members
Posts: 6,874
Joined: Jun 30, 2007
|
#48 id:44648 Posted Mar 28, 2010, 2:57 pm
|
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).
|
|
|
|
|
David Haley
Wizard
Group: Members
Posts: 6,874
Joined: Jun 30, 2007
|
#50 id:44673 Posted Mar 28, 2010, 10:22 pm
|
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.
|
|
|
|
|
Tyche
Wizard
Group: Members
Posts: 1,343
Joined: May 23, 2006
|
#52 id:44703 Posted Mar 29, 2010, 1:49 pm
|
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. :-)
|
.........................   
For now we see through a glass, darkly; but then face to face: now I know in part; but then shall I know even as also I am known.
Last edited Mar 29, 2010, 1:50 pm by Tyche
|
|
