Re: Excellent technical overview of D-BUS

[Richard Frith-Macdonald]

On 1 Sep 2004, at 06:59, Rogelio Serrano wrote:

> On 2004-09-01 13:20:35 +0800 Richard Frith-Macdonald 
> <richard@brainstorm.co.uk> wrote:
>
> [snip]
> > I'm not sure it would be sufficient ... I can't see how it would 
> > handle the case where
> > you ask for a service provided by any host on the network (ie specify 
> > the host name
> > as '*' when creating an NSConnection).  However, there may be a 
> > mechanism for
> > this that I missed.
> > Rewriting DO to use libdbus does not currently seem particularly 
> > useful ...
> > basically it does not seem to provide any technical advantage.  
> > However, if
> > someone was to provide an optional d-bus based implementation 
> > (preferably
> > runtime selectable) which did not break the existing system, I would 
> > see that
> > only as a good thing ... and we would have an opportunity to move 
> > over to
> > it having been able to do a proper comparison of the performance and 
> > features
> > of the old and new code.
> [snip]
>
> I agree. I think it is better to extend gdomap so it becomes D-BUS 
> daemon like .

That's not what I meant.  I don't see any reason to extend gdomap to be 
like the
d-bus daemon.  The two daemons do different jobs, and if we want to use 
something
like d-bus, we should probably just use d-bus.

However, I may be misunderstanding what you mean by 'D-BUS daemon like'.
The other characteristic I can see is that gdomap 'trusts' what it is 
told about the
location of services, and leaves it up to the applications to check 
that they are
connecting to the correct services ... this is fine for security since 
it's easy to put
checking in the applications, but relatively vulnerable to denial of 
service attacks.
On the other hand, d-bus can require servers to identify themselves ...
which decreases the possibilities for DoS attacks, though by no means
eliminating them.  My feeling is that the extra complexity
of dealing with server authorisation within gdomap would not be worth 
the
modest improvement in DoS resistance.

> Then we split the network ipc part from the local ipc part. The 
> network ipc part then becomes a server connected to and a client of  
> the local ipc part. The network ipc part then can use any mechanism to 
> do ipc, like multicast, broadcast, unicast, etc.

While the organizational simplicity of that is appealing, I'm not sure 
it's a good idea.

The gdomap server is just used to look up ports by service name ... 
it's needed in
order to locate a service on the network, but plays no role in the 
actual messaging.

The actual network ipc is all peer-to-peer, which gives maximum 
performance
(using the d-bus daemon, the actual ipc goes from client process to the 
daemon and
from the daemon to the  server process ... double the amount of network 
I/O).

If someone wrote d-bus based DO, they could either go the 'natural' 
route of passing
ipc through the daemon (which is inefficient/slow) or design a scheme 
where the
d-bus daemon is only used for port lookup (a replacement for gdomap) and
subsequent ipc is peer to peer again.  If the d-bus daemon is only used 
for service
lookup, it looks like gdomap would do a better job - as it's purpose 
built for that
while the de-bus daemon is intended for forwarding ipc between 
processes.

If we made gdomap like the d-bus daemon, (ie used it to forward messages
rather than just providing service lookup), we would be making DO less 
efficient.


Currently we have host-local DO via unix domain sockets (NSMessagePort)
except on windows, and this does not require/use gdomap ... since we 
don't
need to look up the  service on the network.  We know it's local and can
look it up via a local database of some sort (eg. the local filesystem).

> If you dont want network DO then dont run the network ipc part.

Yes.