RE: Streams for several parties

Brian Aker <[email protected]> Wed, 24 Dec 2003 10:08:01 -0800
Newsgroups gmane.comp.apache.mod-mp3
Organization TangentOrg
Message-ID <1072289280.8888.83.camel@avenger>
On Wed, 2003-12-24 at 08:47, Matt Block wrote:
> In any event, there were some little problems with this (basically the
> same problems as the shared memory solution).  First off, note that
> a named pipe, at least as implemented in Linux, is a kernel buffer
> of unpredictable length (because it can be set at kernel compile time,
> and we can't find out to what it was set).  So we're guaranteed to
> be out of sync by at least one buffer length if a new listener joins
> after the stream has started.  This may be acceptable in some
> applications, but for my particular application every client must be
> virtually lock-stepped (I'll explain this later).

Each child process had its own named pipe, a master process just looked
at those pipes and wrote blocks to them as it could. Very slow clients
though could lose sync if they did not read quickly enough (since you
don't want to block on the writes).

> One idea I'd had in keeping with your central writer concept was to
> have the readers all read from one spot in shared memory but not
> worry about the timing of it, and have a central writer just update
> the shared memory with, say, 1k at a time.  The readers would sip
> from shared memory in 1k increments, and send that 1k out the stream.
> If their client got hung up, no biggie- when they get back to the
> memory, it will have moved ahead.

You can do a circular queue, the problem is that slower clients still
will lose out if they slip too far behind.

> This has a ton of advantages.  Unfortunately, it still requires the
> writer to know something about the mp3 in order to regulate the
> delivery speed.

You can send as quickly as the client wants to receive, it will handle
the memory issues. The problem is though that you can only load at the
rate of your slowest client in order to remove the issue of slippage.
And since some clients don't slow they time out... bad blocking. 

> Incidentally, my application requires every single client to receive
> information at the same moment.  I have a good sized house with

Yep, I have to worry about blocking :)
  -Brian
-- 
_______________________________________________________
Brian "Krow" Aker, [email protected]
Seattle, Washington
http://krow.net/
http://askbrian.org/
_______________________________________________________
You can't grep a dead tree.