"DBus Embedded" - a clean break

[Rémi Denis-Courmont]

Le jeudi 20 janvier 2011 20:05:08 Havoc Pennington, vous avez écrit :
> On Thu, Jan 20, 2011 at 2:53 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> > - It could be much (10x?) faster - switch to shared memory, posix
> > message queues for data transmission (references to relevant shared
> > memory blocks), do not do any verification
> 
> Do not do any verification is clearly faster, but is already possible
> with a 1-line change to the current code (grep for
> DBUS_VALIDATION_MODE_DATA_IS_UNTRUSTED)

Hmm... AFAIU, that would imply a change to the protocol and specification. The 
final destination namely needs to discard invalid messages instead of closing 
the entire connection.

> > - Switch to peer-to-peer communication as soon as possible while doing
> > the handshake through daemon (minimize context switches, transmission
> > counts).
> 
> Just make a peer to peer connection with existing dbus, both libdbus
> and other implementations can do it. then you can profile this.
> 
> Why not profile other implementations, btw, such as gdbus?
> 
> It doesn't make sense to say "just switch to peer to peer" because p2p
> doesn't have the same functionality. You can already choose daemon or
> direct, but ifi you need the daemon's functionality, then you need it.
> 
> In a desktop context, peer to peer also has the major downside that
> now you need (in theory) N-factorial or so sockets instead of N
> sockets where N = number of apps. So while it might be faster, you
> might also run out of file descriptors. Which actually used to happen
> with ORBit, btw.

In real life, you will never get even close to the complete N! graph.

If a specific application needs to talk to really a lot of peers, it's time 
for it to consider datagram (unconnected) sockets...

> > - Retain the current serialization functionality. However, provide a
> > way to skip it (since people say it's one reason why dbus is slow) and
> > transmit raw binary data very quickly.
> 
> What is your "raw binary" that is so different from the current wire
> protocol? The current protocol is a binary protocol. The
> representation of a double is just the same as the machine's in-memory
> representation of a double, for example.

Indeed, this sounds a bit misinformed. On the other hand, parsing would be a 
lot easier, safer and more extensible if variants had a total bytes length 
(like arrays), and if arrays had an item count in addition to a total bytes 
length.


-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis