It is not that you can't, but that it does not buy you much. If a streaming packet becomes lost, you do not have time for TCP to resend the packet, you just skip one and keep going.
"One big problem (at least with normal implementations) is that the application cannot get at the packets coming after a lost packet until the retransmitted copy of the lost packet is received. This causes problems for real-time applications such as streaming multimedia (such as Internet radio), real-time multiplayer games and voice over IP (VoIP) where it is sometimes more useful to get most of the data in a timely fashion than it is to get all of the data in order."
Secondly, TCP does not send packets until they are full by default, with streaming you may wish to send many smaller packets.
"The stream-oriented nature of TCP is often an inconvenience. Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility (PSH) to ensure that a complete message is transferred in a reasonable time."
TCP is great for files but less suited to real time events. You may wish to consider SCTP as a choice between UDP and TCP.
I have read some where that audio stream on TCP is much better in quality than UDP streaming, so new application are using TCP from audio streaming and UDP for video.
why is this happening, i want some detail documentation on
that.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.