From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: David Miller <davem@davemloft.net>
Cc: javier@collabora.co.uk, eric.dumazet@gmail.com,
lennart@poettering.net, kay.sievers@vrfy.org,
alban.crequy@collabora.co.uk, bart.cerneels@collabora.co.uk,
rodrigo.moya@collabora.co.uk, sjoerd.simons@collabora.co.uk,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/10] af_unix: add multicast and filtering features to AF_UNIX
Date: Mon, 27 Feb 2012 15:00:06 +0100 [thread overview]
Message-ID: <4F4B8C66.5060206@collabora.co.uk> (raw)
In-Reply-To: <20120224.153616.117399887784547022.davem@davemloft.net>
On 02/24/2012 09:36 PM, David Miller wrote:
>
> My first impression is that I'm amazed at how much complicated new
> code you have to add to support groups of receivers of AF_UNIX
> messages.
>
> I can't see how this is better than doing multicast over ipv4 using
> UDP or something like that, code which we have already and has been
> tested for decades.
>
Primary for performance reasons. D-bus is an IPC system for processes in
the same machine so traversing the whole TCP/IP stack seems a little
overkill to me. We will try it though to have numbers on the actual
overhead of using UDP multicast over IP instead of multicast Unix domain
sockets.
We also thought of using Netlink sockets since it already supports
multicast and should be more lightweight than IP multicast. But even
Netlink doesn't meet our needs since our multicast on Unix sockets
implementation has different semantics needed for D-bus:
- total order is guaranteed: If sender A sends a message before B, then
receiver C and D should both get message A first and then B.
- slow readers: dropping packets vs blocking the sender. Although
datagrams are not reliable on IP, datagrams on Unix sockets are never
lost. So if one receiver has its buffer full the sender is blocked
instead of dropping packets. That way we guarantee a reliable
communication channel.
- multicast group acess control: controlling who can join the multicast
group.
- multicast on loopback is not supported: which means we have to use a
NIC (i.e: eth0).
> I really don't want to apply this stuff, it looks bloated,
> complicated, and there is another avenue for doing what you want to
> do.
>
We can work to reduce the implementation complexity and make it less
bloated.
Or you don't like the idea in general?
> Applications have to change to support the new multicast facilities,
> so they can equally be changed to use a real transport that already
> supports multicasting.
Yes, this is not about minimizing user-space application change but to
improve the D-bus performance, or any other framework that relies on
multicast communication on a single machine.
Best regards,
Javier
next prev parent reply other threads:[~2012-02-27 13:59 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-20 15:57 [PATCH 0/10] af_unix: add multicast and filtering features to AF_UNIX Javier Martinez Canillas
2012-02-20 15:57 ` [PATCH 01/10] af_unix: Documentation on multicast unix sockets Javier Martinez Canillas
2012-02-20 15:57 ` [PATCH 02/10] af_unix: Add constant for unix socket options level Javier Martinez Canillas
2012-02-20 15:57 ` [PATCH 03/10] af_unix: add setsockopt on unix sockets Javier Martinez Canillas
2012-02-20 16:20 ` David Miller
2012-02-20 19:13 ` [PATCH 0/10] af_unix: add multicast and filtering features to AF_UNIX Colin Walters
2012-02-21 8:07 ` Rodrigo Moya
2012-02-24 20:36 ` David Miller
2012-02-27 14:00 ` Javier Martinez Canillas [this message]
2012-02-27 19:05 ` David Miller
2012-02-28 10:47 ` Rodrigo Moya
2012-02-28 14:28 ` David Lamparter
2012-02-28 15:24 ` Javier Martinez Canillas
2012-02-28 16:33 ` Javier Martinez Canillas
2012-02-28 19:05 ` David Miller
2012-03-01 11:57 ` Javier Martinez Canillas
2012-03-01 12:26 ` Eric Dumazet
2012-03-01 12:33 ` David Laight
2012-03-01 12:50 ` Rodrigo Moya
2012-03-01 12:59 ` Eric Dumazet
2012-03-01 13:56 ` Javier Martinez Canillas
2012-03-01 16:00 ` Eric Dumazet
2012-03-01 16:02 ` Luiz Augusto von Dentz
2012-03-01 17:06 ` Javier Martinez Canillas
2012-03-01 17:59 ` Eric Dumazet
2012-03-01 18:10 ` Alan Cox
2012-03-01 19:02 ` Javier Martinez Canillas
2012-03-01 19:29 ` Javier Martinez Canillas
2012-03-01 18:53 ` David Dillow
2012-03-01 20:55 ` David Miller
2012-03-02 4:40 ` Stephen Hemminger
2012-03-01 20:44 ` David Miller
2012-03-01 22:01 ` Luiz Augusto von Dentz
2012-03-01 22:08 ` David Miller
2012-03-02 8:39 ` Luiz Augusto von Dentz
2012-03-02 8:55 ` David Miller
2012-03-02 9:27 ` Javier Martinez Canillas
2012-03-02 9:39 ` David Miller
2012-03-02 13:13 ` Eric Dumazet
2012-03-02 16:34 ` Javier Martinez Canillas
2012-03-02 17:08 ` Alan Cox
2012-03-05 8:38 ` Luiz Augusto von Dentz
2012-03-05 14:05 ` Martin Mares
2012-03-05 15:11 ` Javier Martinez Canillas
2012-03-05 15:49 ` Martin Mares
2012-03-05 18:55 ` David Lamparter
2012-03-02 10:08 ` Luiz Augusto von Dentz
2012-03-03 12:20 ` Martin Mares
2012-03-02 22:19 ` david
2012-03-01 12:57 ` Luiz Augusto von Dentz
2012-03-01 20:42 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2012-03-01 14:25 Erik Hugne
2012-03-01 14:25 ` Erik Hugne
2012-03-01 17:18 ` Rodrigo Moya
2012-03-02 7:01 ` Ying Xue
[not found] ` <4F506ABC.8050807@windriver.com>
2012-03-05 15:49 ` Erik Hugne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F4B8C66.5060206@collabora.co.uk \
--to=javier.martinez@collabora.co.uk \
--cc=alban.crequy@collabora.co.uk \
--cc=bart.cerneels@collabora.co.uk \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=javier@collabora.co.uk \
--cc=kay.sievers@vrfy.org \
--cc=lennart@poettering.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rodrigo.moya@collabora.co.uk \
--cc=sjoerd.simons@collabora.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.