On Sun, Mar 29, 2009 at 7:10 PM, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Mon, Mar 30, 2009 at 12:38:38AM +0200, Pau Arumí
wrote:
But in my case I have multiple processes in the
same computer that
listens the same source (another process also in the same computer). If
I understand well multicast, it does not help in my situation, right?
If your destination processes are just waiting for
commands without creating a permantent connection to
the source of these commands (in other words. they
are UDP receivers) then multicast is the way to go.
Instead of listining on a normal IP address the
receivers should join a multicast group. Liblo
does provide this AFAIK. Such a receiver is still
a 'server', which is somewhat misleading.
In particular, the TTL setting on outgoing multicast messages can be
used to make sure the message stays within the local host, if that's
what you intend. So you have pretty good control on how far the
message will go. (Usually one stays within the current subnet.)
When creating a multicast socket you normally need
to provide not only the multicast IP address and
port but also an interface address. Liblo seems
to use INADDR_ANY for this in its multicast receiver,
which is rather strange.
AFAICS liblo does not provide a way to create a multicast
sender. Strangely there is a IP_MULTICAST_TTL option set,
but no I've found no IP_MULTICAST_IF option which would
be required in a sender.
I wrote the multicast implementation, but I'm by no means an expert.
I tried to follow the advice here:
http://www.tldp.org/HOWTO/Multicast-HOWTO.html
If you know of something that could be done better, please don't
hesistate to let me know. From what I understood, setting
IP_MULTICAST_TTL and sending to a multicast group IP address is all
that's required to send a multicast message.
"If the host has more than one interface and the IP_MULTICAST_IF
option is not set, multicast transmissions are sent from the default
interface."
Since I don't regularly deal with anything but the default interface,
I never noticed this omission. Thanks for pointing it out.
Can you give some more details on why INADDR_ANY is strange for the
receiver? Looking further at that document..
"Some considerations: first, note that you don't just join a group.
You join a group on a particular network interface."
Is this what you're referring to?
thanks,
Steve