"DBus Embedded" - a clean break
remi at remlab.net
Thu Jan 20 10:16:56 PST 2011
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
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
More information about the dbus