RE: Streams for several parties

 > -----Original Message-----
 > From: [email protected] 
 > [mailto:[email protected]] On Behalf Of Brian Aker
 > Sent: Monday, December 22, 2003 9:49 PM
 > To: [email protected]
 > Subject: Re: [Mod_mp3] Streams for several parties
 > 
 > 
 > 
 > On Dec 16, 2003, at 9:25 PM, Matt Block wrote:
 > 
 > > This isn't easy to solve.  I thought of putting the 
 > information into
 > > shared memory and having each client read it from there.  
 > One client
 > > was the designated stream reader, and the others just took 
 > what they 
 > > could
 > > from shared memory.  That way the FIFO gets depleted only 
 > as fast as 
 > > the
 > > designated reader reads.  Unfortunately, the other side of 
 > this is that
 > > shared memory fills only that quickly as well, so it may 
 > be that the
 > > other clients block for a bit.  Worse, there is no good 
 > way to know 
 > > when
 > 
 > My solution for this (though not completed in the code) was to have 
 > incoming connections create named pipes and to have one 
 > central reader 
 > write to write to all of these.
 
I went ahead and finished up your code. :)  Unfortunately, I lost
many of my changes to it, so the central writer was lost.

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).

Second, named pipes block readers when the buffer is empty and block
writers when the buffer is full.  Implementing unblocked I/O on them
is a little bit complicated (mostly on the readers).

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.

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.

Incidentally, my application requires every single client to receive
information at the same moment.  I have a good sized house with
computers in every room.  Each computer has pretty good speakers.  I
want to have the option of locking them into a stream.  They need
to be sufficiently synchronized that I can walk throughout the house
without noticing "seams".

	-- Matt