[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Excellent technical overview of D-BUS
From: |
Richard Frith-Macdonald |
Subject: |
Re: Excellent technical overview of D-BUS |
Date: |
Wed, 1 Sep 2004 07:54:02 +0100 |
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.