From: "LiFe" <[EMAIL PROTECTED]>
Subject: Re: TCP mode
Ummm I think you've been misled.
TCP (transmission Control Protocol) and UDP (Something Data Protocol? I
don't know that one hehe) are the 2 main methods of sending packets over the
internet (a packet switched netowrk). They govern the destination of the
packets and the method of getting them there and error correction etc etc.
You then have protocols that use those to protocols to send information over
the internet.
TCP: This protocol has almost 100% reliability. It dictates that every
packet recieved must be acknowladged by the reciever. Any packets not
recieved will be resent. Hence it is great for sending data (FTP - File
Transport Protocol) but is has a great deal of overhead and is hence not
exactly fast.
UDP: This protocol is designed for media where packets can be lost without
any serious effects, but SPEED and little overhead is the most important
feature. A server using UDP sends packets expecting no acknowledgement. If a
packet is lost the client must request retransmission of the packet (and in
some streaming situations the packet may not arrive on time). It sacrifices
reliability for speed.
HTTP: (Hyper Text Transfer Protocol) This protocol is used over TCP (where
TCP governes the delivery of each individual packet of information, and HTTP
governs the request for data, sending the data (in the data portions of the
TCP packets) and the acknowledgement of data). It is basically used for web
pages. Think of it as a conversation between client and server, negotiating
which version of http to use, then what file must be sent, then sending it,
then acknowledging reciept. It sounds like overkill where TCP acknowledges
each individual packets reciept and HTTP acknowledges the recipt of a
file... but well... the net was never fast!
The Real Player has many choices to make (Not neccessarily in this order):
First is must decide wheather the server and your netowrk support UDP (as
this is the fastest protocol - esp for streaming!). If it does not (for
instance the server is a standard web server (HTTP) then it will use TCP and
you've lost a fair amount of performance.
It must also negotiate the protocol the data will be streamed using. RTSP is
the latest protocol that supports UDP (I am pretty certain it supports TCP
too). Using Real products you can use SureStream which really improves
performance over changing network conditions.
PNM is the streaming protocol of the old days (and is still widely used) It
supports UDP and probbaly also TCP. It does not support SureStream.
To use PNM or RTSP you need a server designed specifically for streaming
media - like Real Server. A Web server will not give the same performance.
HTTP is the lucky last and most horrid protocol for streaming media. It is
the same protocol used for sending web pages and involves a decent amount of
overhead. An ordinary web server's whole purpose is to send content using
HTTP so u can use an ordinary web server to stream media this way. It is
slow and inefficient as it does not support UDP (only TCP) or SureStream.
This way is not recommended for a good streaming experience (although it
will work fine). TCP requires a bit of overhead, and HTTP requires a bit of
overhead, which subtracts from the bandwidth avaliable for the stream. HTTP
however is supported by the majority of software (for instance MS's Internet
Information Server and the Real Server) and all networks, hence it is the
"fallback" protocol - or the protocol of choice for people with established
web (http) servers not looking to deploy more software.
So in conclusion:
Leave TCP or UDP to the Real Server (which will determine what is possible
on your network - I'd say 98% of networks support UDP). You only need to
consider this if you are using a Web Server (http).
Update to the latest Real Server (the G2 series) and you can use RTSP (with
the G2 clients) and it will fall back to PNM if a RTSP connection cannot be
made and to HTTP if PNM fails (or so I belive)
If you don't want to update the server then you're stuck with PNM and HTTP
when they fails - not bad, but theres no support for SureStream.
If you don't have any Real Server software you're stuck with HTTP on a web
server. How boring! : ) Get yourself the free Real Server (basic) which will
let u stream up to 20 simultanious RTSP streams, and use your Web Server for
the lesser streams (if you have more than 20 simultanious connections)
Regards,
LiFe.
P.S. All my TCP/IP knowledge has been self taught from bits and pieces.
Please let me know if I have made any mistakes or have some comcepts
completly wrong - which could be very possible! I'm always looking to learn
a bit more.
> From: [EMAIL PROTECTED]
> Subject: TCP mode
>
> Hi,
> I think this is a basic question, just can't find the answer. What is
> TCP protocol and how do you get your realvideo to stream TCP. I know what
> http and udp is but TCP confuses me. It behaves like a http but I noticer
> it loads faster than http it looks better than http. I would appreciate
> any help to clear my confusion.
> Thanks,
> Camille Daniels
>
>
*******************************************************
The RealForum is an email discussion group focused on using RealNetworks
products. The RealForum is a place to post messages about the best methods
for creating content using RealNetworks technologies and the planning and
implementation of streaming-media web sites.
If you ever want to remove yourself from this mailing list,
you can send mail to <[EMAIL PROTECTED]> with the following
command in the body of your email message:
unsubscribe realforum
or from another account, besides the address you subscribed with:
unsubscribe realforum <[EMAIL PROTECTED]>
