Messages in this thread | | | Date | Mon, 22 Nov 2010 20:09:31 +0000 | From | Alban Crequy <> | Subject | Re: [PATCH 7/9] AF_UNIX: Documentation on multicast Unix Sockets |
| |
Le Mon, 22 Nov 2010 21:07:40 +0200, "Rémi Denis-Courmont" <remi@remlab.net> a écrit :
> Le lundi 22 novembre 2010 20:36:20 Alban Crequy, vous avez écrit : > > +Multicast Unix sockets > > +====================== > > + > > +Multicast group memberships are stored in struct unix_mcast nodes. > > An Unix +socket can join several multicast groups. Struct > > unix_mcast nodes are doubly +linked: > > +- In (struct unix_sock)->mcast_subscriptions > > +- In (struct unix_sock)->mcast_members > > I may be stupid, but I found this whole documentation very confusing, > and so the API it tries to describe. Traditionally: > - Senders may or not may be part of the group and are not kept track > of. > - Receivers join to the group then receive message sent to it. > - Loopback defines whether a sender receives its own echo if it sends > to a group that it has joined. > - If connected to a multicast group, messages from the socket are > routed to the group (in absence of a contradictoy socket address). > This has no effect on membership to the multicast group under any > circumstance.
I keep these traditional properties for multicast on Unix sockets.
> You cannot 'listen' or 'accept' on a multicast group.
Datagram sockets cannot listen() or accept() but seqpacket sockets can. I would like multicast to work on seqpacket sockets too. In this case, there is a central daemon who listen(), and accept() returns a new socket. The central daemon controls the lifetime of the multicast group and can receive the messages from the peers on the socket returned by accept() if UNIX_MREQ_SEND_TO_PEER is set.
The accepted socket could join the multicast group (and then receive messages addressed to the group) with the setsockopt() call, but then there would be a race that it may not receive the first messages if a peer connect() and send a message immediately afterwards. connect() can returns on the peer process before the daemon accept() and runs setsockopt(). I added the flag UNIX_MREQ_AUTOJOIN (to be set when creating the multicast group) to prevent that race.
Using connected sockets (seqpacket) is useful for D-Bus because a central daemon can know when members are connecting and disconnecting and then emit the D-Bus signal 'NameOwnerChanged'.
> So I am not entirely clear what semantics your patchset is following. > But it does not seem like "multicast" to me and therefore seems not > very well documented :-(
I am willing to improve it.
-- Alban -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |