Re: [systemd-devel] Compatibility between D-Bus and kdbus

Thiago Macieira <[email protected]>
Newsgroups gmane.comp.freedesktop.dbus
Message-ID <2117730.Hv0KXE1yMi@tjmaciei-mobl4>
On Tuesday 25 November 2014 17:19:41 Lennart Poettering wrote:
> On Mon, 24.11.14 18:40, Thiago Macieira ([email protected]) wrote:
> > Another thought that comes to mind: should we reserve the entire highest
> > bit in connection IDs for broadcasts? It would allow for the existence of
> > multicast groups in the future.
> 
> I discussed this quickly with the kdbus guys, and while none of us was
> thrilled about the posibility of introducing such a concept we all
> agreed that if it should be introduced one day it really should be
> part of the well-known names concept, not the unique names
> concept. Meaning: you'd put a label on a group, and join the group by
> the label then, rather than via numeric ids...
> 
> In general, numeric ids are about being automatic, and well-known
> names are about discoverability. But mcast memberships should never be
> automatic, but only about discoverability, hence using unique ids for
> identifying them sounds wrong.

Agreed that mcast memberships should not be automatic. Just like IPv4 and 
IPv6, joining a multicast group requires placing a request.

I was thinking more on the fact that 802 MAC addresses have a bit to indicate 
multicast/broadcast data.

Can I suggest the following two changes to kdbus.txt when it comes to 
connection IDs:

1) remove the part that the numbers are not reused
2) say that the highest bit is reserved for future purposes

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

_______________________________________________
dbus mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dbus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.