Re: [PATCH 0/10] af_unix: add multicast and filtering features toAF_UNIX

[Erik Hugne]

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@xxxxxxxxxxxxxxx
> >  More majordomo info athttp://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/