Icecast dev - Aug 2004 - Re: PATCH: increase network congestion resilience

On Saturday 18 January 2003 03:37, Michael Smith shaped the electrons to 
shout:
> We can't just drop packets, the transmission model assumed by the
> format handlers (and required by at least one of them) will not permit
It's not vorbis. Does it?
> us to drop any data. It'd be possible, in theory at least, to tag
> buffers with a flag to say that they can be dropped, but probably not
> worth the complexity.
I think it's ok as a last resort technique for trying to maintain alive a 
connection. Dropping some packages is much better that just closing the 
connection. Indeed, I checked with few players and all of them recover 
just fine. You have to be concentrated to notice the drops.
> Erroring out if the client hasn't received any data within some timeout
> may be a good idea, but needs some cleanup.
That the reason I moved all client buffer delivery logic to just one 
function (now receiving from sources and delivery to clients are all 
embeded in just one function). I will give a shot again.


-- 
  ricardo galli       GPG id C8114D34

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Sunday 19 January 2003 01:59, Ricardo Galli wrote:
> On Saturday 18 January 2003 03:37, Michael Smith shaped the electrons to
>
> shout:
> > We can't just drop packets, the transmission model assumed by the
> > format handlers (and required by at least one of them) will not permit
>
> It's not vorbis. Does it?
>
Vorbis certainly DOES require us to not drop packets. It'll work most of the
time, but if you happen to do it at the wrong time, you'll end up sending a 
corrupt stream to the client. This is a bad idea.
> > us to drop any data. It'd be possible, in theory at least, to tag
> > buffers with a flag to say that they can be dropped, but probably not
> > worth the complexity.
>
> I think it's ok as a last resort technique for trying to maintain alive
a
> connection. Dropping some packages is much better that just closing the
> connection. Indeed, I checked with few players and all of them recover
> just fine. You have to be concentrated to notice the drops.
Yeah, you've been lucky (well, not THAT lucky, you're relatively
unlikely to
hit the broken cases) and not done this at one of the times where it will 
cause errors.

Doing it correctly is harder than it looks.

Mike

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Saturday 18 January 2003 16:04, Michael Smith shaped the electrons to 
shout:
> On Sunday 19 January 2003 01:59, Ricardo Galli wrote:
> > On Saturday 18 January 2003 03:37, Michael Smith shaped the electrons
> > to
> >
> > shout:
> > > We can't just drop packets, the transmission model assumed by
the
> > > format handlers (and required by at least one of them) will not
> > > permit
> >
> > It's not vorbis. Does it?
>
> Vorbis certainly DOES require us to not drop packets. It'll work most
> of the time, but if you happen to do it at the wrong time, you'll end
> up sending a corrupt stream to the client. This is a bad idea.
...
> Yeah, you've been lucky (well, not THAT lucky, you're relatively
> unlikely to hit the broken cases) and not done this at one of the times
> where it will cause errors.
In icecast/vorbis each refbuf is composed of a entire page, and the 
documentation (http://www.xiph.org/ogg/vorbis/doc/oggstream.html) states 
that a page contains the necessary headers to reconstruct the packetsand 
re-sync the stream. So, the players must be able continue playing if it 
receives an out of sequence page. 

Because a refbuf is a page, we could drop them all but the logical stream 
headers, which are cached and sent first (easy to check). So, before 
discarding a page, we should check is "complete" (in the sense that
the
headers were not already sent, i.e. client->pos == 0) and that is not a a 
pre_data.

OTH, it seems logic and without that property icecast wouldn't work: when 
a new client connects, icecast sends it a pre_data and then start with 
the first available _random_ refbuf. What's the problem with
"restarting"
the stream with a "new", out of sequence, refbuf?

But I could be missing something, sorry if so.

<p>
-- 
  ricardo galli       GPG id C8114D34

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.