Question : Broadcast Inter Process Communication ?

Question : Broadcast Inter Process Communication ?

[Jean Tourrilhes]

	Hi everybody,

	I was looking under Linux for a mechanism to distribute an
event from one process (a daemon) to a set of other processes (deamons
or applications). The number and indentity of those other processes
would not be known by the process generating the event, those
processes would register themselves dynamically to the stream of
event. And the event need to be delivered to all of them (not only the
first one).
	In other words, it would look like a *broadcast* message
queue, where the sender process would create the queue and write
events to it, and the other bunch of processes would dynamically open
the queue and listen for events.
	My first attempt was with IPC message queues, but my
experimentations show that only the first receiver get the message. It
is pretty clear that no amount of tweaking will get the IPC message
queue to behave like that : IPC message queues don't have a notion of
receiver session, so can't send message to all receivers.
	I can't use signals because signals are unicast, and I don't
want the sender to have to manage a list of processes it has to send
signals to. Also, signals don't have payload and are synchronous.
	Unix sockets don't have a broadcast mode, and therefore are
limited to a single receiver (actually, I think you can only have one
sender). In theory, you could implement a broadcast mode for Datagram
sockets using the current API, it's just not done today.
	I don't really want to use a UDP broadcast socket for
efficiency reason (and also because I don't want those events to go
accidentally over the network, or beeing succeptible to receive
spoofed events from the network). Also, it require the network stack
to be active and properly configured. But I must admit a UDP broadcast
on the loopback does pretty much what I need.
	Failing that, I could hack a kernel module to do that, but I
don't want to re-invent the wheel...

	This "one sender - multiple reader" model seems common and
usefull enough that there must be a way to do that under Linux. I know
that it exist under Windows. Can somebody help me to find out how to
do it under Linux ?
	Thanks in advance...

	Jean

Re: Question : Broadcast Inter Process Communication ?

[Olaf Dietsche]

Hi Jean,

Jean Tourrilhes <jt@bougret.hpl.hp.com> writes:

> 	I was looking under Linux for a mechanism to distribute an
> event from one process (a daemon) to a set of other processes (deamons
> or applications). The number and indentity of those other processes
> would not be known by the process generating the event, those
> processes would register themselves dynamically to the stream of
> event. And the event need to be delivered to all of them (not only the
> first one).
> 	In other words, it would look like a *broadcast* message
> queue, where the sender process would create the queue and write
> events to it, and the other bunch of processes would dynamically open
> the queue and listen for events.

[snip]

> 	This "one sender - multiple reader" model seems common and
> usefull enough that there must be a way to do that under Linux. I know
> that it exist under Windows. Can somebody help me to find out how to
> do it under Linux ?


Maybe, you're looking for multicast. But you need a TCP/IP stack for
this and I don't know, wether this is implemented in Linux.

Regards, Olaf.

Re: Question : Broadcast Inter Process Communication ?

[Jean Tourrilhes]

On Sat, May 18, 2002 at 03:52:33AM +0200, Olaf Dietsche wrote:
> Hi Jean,
> 
> > 	This "one sender - multiple reader" model seems common and
> > usefull enough that there must be a way to do that under Linux. I know
> > that it exist under Windows. Can somebody help me to find out how to
> > do it under Linux ?
> 
> 
> Maybe, you're looking for multicast. But you need a TCP/IP stack for
> this and I don't know, wether this is implemented in Linux.

	I've used multicast with great success in the past and I know
that it's possible to bind a multicast socket on an interface. So,
basically I would bind a multicast socket on the loopback. That what I
was refering to in my e-mail by "UDP broadcast".
	But, it just seems to me inefficient to have to go through all
the way down in the network stack to the loopback interface (through
IP and TCP) just for simple IPC. A multicast unix socket would be much
more efficient (because it would no mess with any headers and support
higher MTU).

> Regards, Olaf.

	Thanks...

	Jean

Re: Question : Broadcast Inter Process Communication ?

[Jean Tourrilhes]

On Sat, May 18, 2002 at 04:04:52AM +0100, Alan Cox wrote:
> > 	This "one sender - multiple reader" model seems common and
> > usefull enough that there must be a way to do that under Linux. I know
> > that it exist under Windows. Can somebody help me to find out how to
> > do it under Linux ?
> 
> Its actually a nontrivial construct - especially since readers can vanish
> and appear asynchronously during the lifetime of any event.

	That's exactly why I don't want to deal with it myself.
	However, the kernel deal with it all the time, and do it
well. For example RtNetlink event have this property (except that they
are kernel => process instead of beeing process => process).

> You could 
> implement it with multiple linked lists of pointers to refcounted objects,
> and you could do that in user space (eg with shared memory), the chances
> are that for all but the most extreme cases sending a copy of the event to
> each listener is cheaper, simpler and more debuggable

	Well, maybe I will simply use a UDP broadcast on the loopback,
it seems much simpler to me. I really wish there was broadcast Unix
sockets.

	Regards,

	Jean

Re: Question : Broadcast Inter Process Communication ?

[Alan Cox]

> 	This "one sender - multiple reader" model seems common and
> usefull enough that there must be a way to do that under Linux. I know
> that it exist under Windows. Can somebody help me to find out how to
> do it under Linux ?

Its actually a nontrivial construct - especially since readers can vanish
and appear asynchronously during the lifetime of any event. You could 
implement it with multiple linked lists of pointers to refcounted objects,
and you could do that in user space (eg with shared memory), the chances
are that for all but the most extreme cases sending a copy of the event to
each listener is cheaper, simpler and more debuggable

Re: Question : Broadcast Inter Process Communication ?

[Alan Cox]

> 	That's exactly why I don't want to deal with it myself.
> 	However, the kernel deal with it all the time, and do it
> well. For example RtNetlink event have this property (except that they
> are kernel => process instead of beeing process => process).

By sending one copy of the message to each target. Its how everyone does
it except for special cases. Reliable multi-delivery is -hard-

Re: Question : Broadcast Inter Process Communication ?

[Maksim (Max) Krasnyanskiy]

> >       That's exactly why I don't want to deal with it myself.
> >       However, the kernel deal with it all the time, and do it
> > well. For example RtNetlink event have this property (except that they
> > are kernel => process instead of beeing process => process).
>
>By sending one copy of the message to each target. Its how everyone does
>it except for special cases. Reliable multi-delivery is -hard-

I was gonna suggest the same thing. Why not just have a simple event server 
based on unix sockets.
This server would listen on unix stream socket. Clients interested in 
events would connect to it.
All the server has to do is copy event to all connected clients.
Server code is very simple. About 20 lines, everything in a single thread, 
if you use GLib's event loop.

Max 

Re: Question : Broadcast Inter Process Communication ?

[Peter Wächtler]

Maksim (Max) Krasnyanskiy wrote:
> 
>> >       That's exactly why I don't want to deal with it myself.
>> >       However, the kernel deal with it all the time, and do it
>> > well. For example RtNetlink event have this property (except that they
>> > are kernel => process instead of beeing process => process).
>>
>> By sending one copy of the message to each target. Its how everyone does
>> it except for special cases. Reliable multi-delivery is -hard-
> 
> 
> I was gonna suggest the same thing. Why not just have a simple event 
> server based on unix sockets.
> This server would listen on unix stream socket. Clients interested in 
> events would connect to it.
> All the server has to do is copy event to all connected clients.
> Server code is very simple. About 20 lines, everything in a single 
> thread, if you use GLib's event loop.
> 

If using a central "server" process, all clients have to copy
the message to the server - then the server copies the messages
to multiple clients.

I can imagine a library, that holds a registry in shared mem, and
the clients look for themselves to whom to copy the message.
For this I want to use posix message queues to avoid lots of
context switches and copies.