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.