Messages in this thread | | | Date | Thu, 1 Mar 2012 14:57:51 +0200 | Subject | Re: [PATCH 0/10] af_unix: add multicast and filtering features to AF_UNIX | From | Luiz Augusto von Dentz <> |
| |
Hi Javier,
On Thu, Mar 1, 2012 at 1:57 PM, Javier Martinez Canillas <javier.martinez@collabora.co.uk> wrote: > On 02/28/2012 08:05 PM, David Miller wrote: >> From: Rodrigo Moya <rodrigo.moya@collabora.co.uk> >> Date: Tue, 28 Feb 2012 11:47:39 +0100 >> >>> Because of all of this, UDP/IP multicast wasn't even considered as an >>> option. We might be wrong in some/all of those, so could you please >>> comment on them to check if that's so? >> >> You guys seem to want something that isn't AF_UNIX, ordering guarentees >> and whatnot, it really has no place in these protocols. >> >> You've designed a userlevel subsystem with requirements that no existing >> socket layer can give, and you just figured you'd work that out later. >> >> I think you rather should have reconsidered these premises and designed >> something that could handle reality which is AF_UNIX can't do multicast >> and nobody guarentees those strange ordering requirements you seem to >> have. > > Yes, you are right it doesn't follow AF_UNIX semantics so Unix sockets > is not the best place to add our multicast implementation. > > So, now we are trying a different approach. To create a new address > family AF_MCAST. That way we can have more control over the semantics of > the socket interface for that family. > > We expect to have some patches in a few days and we will resend.
Lets say AF_MCAST is acceptable, wouldn't it make AF_UNIX obsolete? From what I can tell a lot, if not most, of users of AF_UNIX uses it to implement some kind of IPC being it D-Bus, chromium or wayland and eventually all of them run into the same problems. Actually the article in lwn put it nice together: http://lwn.net/Articles/466304/
What about SCM_RIGHTS and other Ancillary Messages, would that be acceptable in other socket families?
-- Luiz Augusto von Dentz
| |