Hi On Sun, Nov 05, 2006 at 11:56:45AM -0500, Rich Felker wrote:
On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
also nut is no network protocol, i have my doubts it will be used raw in such a streaming case ...
It could, there's no real reason you can't just TCP NUT over some simple protocol. Oh no, I'm turning into Ivan :)
Indeed, TCP is the _sane_ method for streaming. All these fancy protocols are for the stupid case where you're saturating the network. If there's any chance that the recipient wants to record the stream, it needs reliable delivery anyway and should just be using TCP.
yes, but there are a few issues ... routers might give priority to fancy protocols relative to TCP when it comes to what to send out first, (no i dunno if thats the case iam just guessing) packets can be lost even if the network isnt saturated, and the retransmit will cause the following few packets to arrive later unless you have >= 2x the bandwidth available then what you use and the OS might not give the user app the next data until it has successfully received the retransmitted packet and normal people will complain if they notice problems even just once per hour in a conversation on the phone they will also complain if you add some extra delay to hide the effects of one retransitted packet iam not saying NUT over TCP is silly, iam just saying that with current TCP implementations its not optimal maybe the solution would rather be to change the client TCP implementation so that it gives all packets immedeatly to the user and gives the user the option to send dummy acknowledge packets foe specific missing packets so that no unneccessary retransmits happen ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is