[NUT-devel] Info packets in NUT stream (spec bugs?)

[Michael Niedermayer]

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