Re: UPD better than TCP in streaming video/audio ?
From: Alun Jones [MSFT] (alunj_at_online.microsoft.com)
Date: 12/07/04
- Next message: Jamesly: "RE: Multicast Exception in >NET 1.1 and WinXP SP2!!"
- Previous message: Dean Roddey: "Re: Name resolution vis a vis an ORB (Part II, the Revenge)"
- In reply to: Puzzolino: "UPD better than TCP in streaming video/audio ?"
- Next in thread: Puzzolino: "Re: UPD better than TCP in streaming video/audio ?"
- Reply: Puzzolino: "Re: UPD better than TCP in streaming video/audio ?"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 6 Dec 2004 16:00:56 -0800
"Puzzolino" <puzzolino77@libero.it> wrote in message
news:bRYrd.249679$b5.12176420@news3.tin.it...
> can UDP achieve better performance then TCP ?
> Where can I find more info ?
The key is not so much that one outperforms the other (because if that were
all that's at stake, nobody would bother with the lower-performance
protocol.
UDP gains speed over TCP because it carries no information that would allow
you to determine the order that data was sent in, and because it has no
handling for lost data - not only doesn't it retry packets that got lost
along the way, it doesn't even know that packets were lost.
This makes it useful for protocols where out-of-order and lost or duplicated
packets are not a problem.
TCP, on the other hand, carries sequence information, and uses
acknowledgements to allow a sender to re-send any data that is not received
(and acknowledged) in a timely manner. Thus, TCP is a 'reliable' protocol -
it takes measures to ensure that the data gets there.
This makes it useful for protocols where speed is less of a problem than the
importance of data reaching its destination intact and in order.
So, for instance, if you're transmitting a file, you need all the data to
get to the receiver. TCP is great for that - although the file doesn't
necessarily have to arrive in sequence, it has to be assembled into
sequence, and you have to be able to tell whether all the data has been
received or not, and the simplest solution to that problem is not to allow
byte N to be written until after byte N-1 has.
If you're transmitting your location, however, you're more likely to care
about where you are right now, rather than a detailed plot of everywhere you
have been - a half a second or so of missing data is not likely to lead to
you becoming lost, especially if some of the data is getting through to you.
Streaming media is a classic example of "don't care if some of the data
doesn't get there", which is perfect for UDP.
But if you're downloading a movie to burn onto a DVD-R for later viewing,
you want all the bits, so that there aren't any skips in the sound or
picture, and so that you don't get a degradation in picture or sound
quality. Such an application would do best to use TCP.
Every so often, people come up with the idea of taking UDP because it's
faster than TCP, and forget to take into consideration its lack of
reliability. Then they realise that their application requires reliability,
and they add on features to support it. What they end up with is a rewrite
of TCP that has few of the features, little of the clever thinking, and is
slower and more network-heavy.
Finally, there's the possibility of multicast data - for instance, a live
broadcast from a radio station on the Internet. This would be a great use
of multicast UDP, because a) it's streaming media, and occasional lossiness
is fine, and b) multicasting it would mean that at most one copy of each
datagram would traverse each link along the path between the radio station
and its listeners, significantly reducing the traffic cost of popular
stations (and adding almost nothing to the traffic cost of stations with
only one person listening). Sadly ISPs have been reluctant to allow
multicast traffic, and it's been difficult to implement multicast on an
Internet-wide basis.
Alun.
~~~~
-- Software Design Engineer, Internet Information Server (FTP) This posting is provided "AS IS" with no warranties, and confers no rights.
- Next message: Jamesly: "RE: Multicast Exception in >NET 1.1 and WinXP SP2!!"
- Previous message: Dean Roddey: "Re: Name resolution vis a vis an ORB (Part II, the Revenge)"
- In reply to: Puzzolino: "UPD better than TCP in streaming video/audio ?"
- Next in thread: Puzzolino: "Re: UPD better than TCP in streaming video/audio ?"
- Reply: Puzzolino: "Re: UPD better than TCP in streaming video/audio ?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
