[ale] Stupid socket tricks

[Mike Kachline]

On Mon, 18 Dec 2000, Glenn C. Lasher Jr. wrote:

<snip>
> What I am trying to do is cause data from one process to be distributed to
> multiple processes, some of which may or may not be there, but the data is
> real-time, and any data that was there before a receiving process started
> is not to be delivered to that process.  (the application is an MP3
> streamer)
<snip>

	Glen,

	To start off with, I'm assuming that you can use C (though, perl
probably has most of these constructs too).

	This sounds like a good candidate for a multi-threaded model. One
thread creates the MP3 data and places that data into a circular 
queue. All other threads handle incoming connections (either IP, Unix
domain, etc.), take data out of the circular queue and send it to the
appropriate client or end user.

	Barring threads, my next hunch would be a server which listens on
a unix domain socket for connections from clients. Clients would connect
to the server's unix domain socket, read() from the ud socket, then
write() to the end user. The server would create it's data, select() on
client, unix domain connections which are writable, and write to
those. Any connections which don't select() to be writable don't get the
current time's data and aren't written to.

	A final, solution would be to use shared memory. Have the server
post it's data to a circular queue within a shared memory region. As
clients come and go, they simply attach to, then read from the shared
memory region as they need. If quality of data matters, then you'd want to
use a semaphore to ensure that the server doesn't write over a region of
the queue at exactly the same time a client is reading from it.

	If you have Steven's "Advanced Programming in the Unix
Environment" (and you should own this book if you're asking questions
like this), you'll find each of these topics discussed in excellent
nature there. Let me know if you have any other questions, and I can go
into more detail as appropriate.



				- Mike
======================================
Michael Kachline 
mailto:kachline at brightstar.gt.ed.net
http://brightstar.gt.ed.net/kachline
======================================

--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.