From: Erik Hugne <erik.hugne@ericsson•com>
To: Ying Xue <ying.xue@windriver•com>
Cc: Rodrigo Moya <rodrigo.moya@collabora•co.uk>,
"netdev-owner@vger•kernel.org" <netdev-owner@vger•kernel.org>,
"David.Laight@ACULAB•COM" <David.Laight@aculab•com>,
"davem@davemloft•net" <davem@davemloft•net>,
"javier@collabora•co.uk" <javier@collabora•co.uk>,
"lennart@poettering•net" <lennart@poettering•net>,
"kay.sievers@vrfy•org" <kay.sievers@vrfy•org>,
"alban.crequy@collabora•co.uk" <alban.crequy@collabora•co.uk>,
"bart.cerneels@collabora•co.uk" <bart.cerneels@collabora•co.uk>,
"sjoerd.simons@collabora•co.uk" <sjoerd.simons@collabora•co.uk>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"linux-kernel@vger•kernel.org" <linux-kernel@vger•kernel.org>,
"eric.dumazet@gmail•com" <eric.dumazet@gmail•com>
Subject: Re: [PATCH 0/10] af_unix: add multicast and filtering features to AF_UNIX
Date: Mon, 5 Mar 2012 16:49:00 +0100 [thread overview]
Message-ID: <4F54E06C.3010306@ericsson.com> (raw)
In-Reply-To: <4F506ABC.8050807@windriver.com>
netdev is probably not the right channel to discuss how to use service
partitioning in TIPC, but i think that Yings suggestion using a
"system-bus" publication, and separate d-bus user publications is sound.
One problem is that TIPC does not support passing FD's between processes
(SCM_RIGHTS anc. data).
But adding support for this in TIPC should have a relatively small code
footprint.
//E
On 2012-03-02 07:37, Ying Xue wrote:
> Hi Rodrigo,
>
> I try to answer your questions about TIPC, please look at comments inline.
>
>
> Rodrigo Moya wrote:
>> Hi Erik
>>
>> On Thu, 2012-03-01 at 15:25 +0100, Erik Hugne wrote:
>>
>>> Hi
>>> Have you considered using TIPC instead?
>>> It already provides multicast messaging with guaranteed ordering, and reliable delivery (SOCK _RDM)
>>>
>>>
>> I didn't know about TIPC, so have been having a quick look over it, and
>> have some questions about it:
>>
>> * since it's for cluster use, I guess it's based on AF_INET sockets? if
>> so, see the messages from Luis Augusto and Javier about this breaking
>> current D-Bus apps, that use fd passing, for out-of-band data
>>
>>
> No, TIPC doesn't depend on AF_INET socket, instead it uses a separate address
> family(AF_TIPC.).
>> * D-Bus works locally, with all processes on the same machine, but there
>> are 2 buses (daemons), one for system-related interfaces, and one per
>> user, so how would this work with TIPC. Can you create several
>> clusters/networks (as in TIPC addressing semantics) on the same machine
>> on the loopback device?
>>
>
> TIPC can both support two modes: single node mode and network mode.
> If we hope all application can easily talk each other locally, let TIPC just
> work under single node mode.
> Of course, it is in network mode, it also supports single node.
>
> How to let TIPC in the single node mode?
> It's very easy, and no any specific configuration is needed. After insert TIPC
> module, it enters into the mode by default.
>
> As Erik specified, TIPC multicast mechanism is very useful for D-Bus. It has
> several cool and powerful special features:
> 1. It can guarantee multicast messages are reliably delivered in order.
> 2. It can support one-to-many and many-to-many real-time communication within
> node or network.
> 3. It also can support functional addressing which means location transparent
> addressing allows a client application to access a server without having to know
> its precise location in the node or the network. The basic unit of functional
> addressing within TIPC is the /port name/, which is typically denoted as
> {type,instance}. A port name consists of a 32-bit type field and a 32-bit
> instance field, both of which are chosen by the application. Often, the type
> field indicates the class of service provided by the port, while the instance
> field can be used as a sub-class indicator.
> Further support for service partitioning is provided by an address type called
> port name sequence. This is a three-integer structure defining a range of port
> names, i.e., a name type plus the lower and upper boundary of the instance
> range. This addressing schema is very useful for multicast communication. For
> instance, as you mentioned, for D-Bus may need two different buses, one for
> system, another for user. In this case, when using TIPC, it's very easy to meet
> its requirement. We can assign one name type to system bus, and another name
> type is to user bus. Under one bus, we also can divide it into many different
> sub-buses with lower and upper. For example, once one application publishes one
> service/port name like {1000, 0, 1000} as system bus channel, any application
> can send messages to {1000, 0, 100} simultaneously. Of course, for example, one
> application can publish {1000, 0, 500} as sub-bus of the system bus, another can
> publish {1000, 501, 1000} as another system sub-bus. At the moment, one
> application can send a message to {1000, 0, 1000} port, it means the two
> applications including published {1000, 0, 500} and {1000, 501, 1000} all can
> receive the message.
>
> If D-Bus uses this schema, I believe the central D-Bus daemons is not necessary
> any more. Any application can directly talk each other by one-to-one,
> one-to-many, and many-to-many way.
>
> 4. TIPC also has another important and useful feature which allows client
> applications to subscribe one service port name by receiving information about
> what port name exist within node or network. For example, if one application
> publishes one system bus service like {1000, 0, 500}, any client applications
> which subscribe the service can automatically detect its death in time once the
> application publishing {1000, 0, 500} is crashed accidentally.
>
> In all, it also have other useful features, about more detailed information,
> please refer its official web site: http://tipc.sourceforge.net/
>
>
>> * I installed tipcutils on my machine, and it asked me if I wanted to
>> setup the machine as a TIPC node. Does this mean every machine needs to
>> be setup as a TIPC node before any app makes use of it? That is, can I
>> just create a AF_TIPC socket on this machine and just make it work
>> without any further setup?
>>
> No, as I indicate before, it's no extra configuration if you expect it just
> works in single node mode.
> Actually there has several demos in tipcutils package, you can further lean
> about its functions and how to work etc.
>
>> * I guess it is easy to prevent any TIPC-enabled machine to get into the
>> local communication channel, right? That is, what's the security
>> mechanism for allowing local-only communications?
>>
>>
> When publishing service name, you can specify the level of visibility, or
> /scope/, that the name has within the TIPC network: either /node scope/,
> /cluster scope/, or /zone scope/.
> So if you want it is just valid locally, you can designated it as node scope,
> which TIPC then ensures that only applications within the same node can access
> the port using that name.
>
> Regards,
> Ying
>
>> I'll stop asking questions and have a deeper look at it :)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message tomajordomo@vger•kernel.org
>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>>
>>
>
next prev parent reply other threads:[~2012-03-05 15:49 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-01 14:25 [PATCH 0/10] af_unix: add multicast and filtering features to AF_UNIX 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 [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-02-20 15:57 Javier Martinez Canillas
2012-02-20 19:13 ` Colin Walters
2012-02-21 8:07 ` Rodrigo Moya
2012-02-24 20:36 ` David Miller
2012-02-27 14:00 ` Javier Martinez Canillas
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
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=4F54E06C.3010306@ericsson.com \
--to=erik.hugne@ericsson$(echo .)com \
--cc=David.Laight@aculab$(echo .)com \
--cc=alban.crequy@collabora$(echo .)co.uk \
--cc=bart.cerneels@collabora$(echo .)co.uk \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=javier@collabora$(echo .)co.uk \
--cc=kay.sievers@vrfy$(echo .)org \
--cc=lennart@poettering$(echo .)net \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev-owner@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=rodrigo.moya@collabora$(echo .)co.uk \
--cc=sjoerd.simons@collabora$(echo .)co.uk \
--cc=ying.xue@windriver$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox