Linus Is Looking Forward To Merging KDBUS, But Not Convinced By Performance

[duby229]

Ok, we'll switch to using sockets. Great. Now every application and it's dog has a slightly different protocol, and it's nearly impossible to interconnect things that were not designed specifically to interconnect. And throw security out the window too, because now every damn application handles that differently.

Or we could just use kdbus, which is now more capable of handling large amounts of data than dbus ever was.

Oh I seriously can't wait for that. I'm gonna be able to say "I told you so" so hard!

As soon as dumbasses start throwing large data onto dbus, Oh the fuel I'll have against those fools.

[gens]

dbus is the protocol for sending/receiving data, you're talking about specific interfaces, where as if everyone invents their own alternative to sending data via sockets you're bound to end up with a bunch of incompatible solutions using different protocols.



I mean that it is then up to each application to handle the security of its IPC, instead of relying on something that is designed exactly for that purpose. The same exact problem as above.

what do you mean by "if everyone invents their own alternative to sending data via sockets"
on linux you have only sockets (a few types), named/normal pipes and shm (few ways to obtain)

the msg transport layer does not matter if all you do is send/receive msgs to clients
with UDS you can even broadcast a msg

UDS even lets you find out the PID of the sending process, from it you can find out anything about it


do give me an example of a security flaw of just sending data over UDS
it cant be sniffed, it cant be faked, idk what you can do to compromise it

maybe you are thinking of sending data that makes the program like, idk, copy msg contents to an arbitrary address in memory ?
i imagine that only happening with a shm protocol, if the msg parser is really broken (like, idk, telling it the data length is 10MB)

if the program tilts on a invalid msg it will tilt on an invalid msg
that will happen if the msg was sent over UDP, TCP, UDS, dbus, fifo, whatever
there is nothing specific to something like UDS that would make it any more or less vulnerable

thx for inciting me to validate my statements
it made me find this handy overview of UDS


EDIT:

that reminds me that UDS needs a file somewhere
and a filesystem is a namespace (despite what many seem to think)
so to discover a "service" one would only need to check if the file is there

[duby229]

Well, he didn't exactly say he was looking forward to merging it. I think really what he said was that he trusts the people he surrounds himself with, and so he'll merge it to keep the system working.

[psychoticmeow]

you are still making your own IPC version, since you are sending arbitrary data over a bus
org.mplayer.whatever is not the same as org.vlc.whatever

if you made a org.videoplayer.whatever, you made a standard "videoplayer" protocol
but then the underlying transport protocol does not matter in the slightest

dbus is the protocol for sending/receiving data, you're talking about specific interfaces, where as if everyone invents their own alternative to sending data via sockets you're bound to end up with a bunch of incompatible solutions using different protocols.

do explain the security part
an example would be even better

I mean that it is then up to each application to handle the security of its IPC, instead of relying on something that is designed exactly for that purpose. The same exact problem as above.

[gens]

Ok, we'll switch to using sockets. Great. Now every application and it's dog has a slightly different protocol, and it's nearly impossible to interconnect things that were not designed specifically to interconnect. And throw security out the window too, because now every damn application handles that differently.

you are still making your own IPC version, since you are sending arbitrary data over a bus
org.mplayer.whatever is not the same as org.vlc.whatever

if you made a org.videoplayer.whatever, you made a standard "videoplayer" protocol
but then the underlying transport protocol does not matter in the slightest


do explain the security part
an example would be even better

[gens]

No, the _protocol_ isn't complex. The reference implemenation may be because it was made to run on Linux/Unix/BSD/Windows/Mac.

Again, you are missing the point; your "solution" would never work like D-Bus unless you invent and duplicate D-Bus for your data channels. Your solution simply can't solve the problems that kdbus/D-Bus solves.

And again, if you try to add marshaling, broadcasting and message queues to your solution, you have in fact invented a new IPC that only works on Linux and isn't supported by a single piece of software.

kdbus on the other hand, will instantly upgrade the entire D-Bus-using Linux userland to a new kernel IPC, without anybody needing to change a line of code.

The kdbus solution also mean that Unix/BSD and non-systemd distros aren't left behind by systemd-distros migrating to a new IPC.

http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol

the protocols first byte is an endianness flag
-it deals with endianness, that no sane protocol should
-the "flag" is one byte, instead of 1 bit
2nd byte is msg type, theres 3 (plus error and "unknown")
3rd byte is an OR of 3 flags
4th is the protocol version (mind you this goes in every msg)
then there are 2 32bit paramaters, data length and a cookie
and still no data, data comes after additional paramater fields that depend on msg type and flags

that's just a basic msg format, the protocol defines a lot more things
maybe you are thinking about the API

and no, i never said you should reinvent broadcasting
i specifically said that dbus should not be used for latency or throughput sensitive problems
for example; using dbus to discover/connect to a media player is fine, while using dbus to actually transport the media is not

[psychoticmeow]

if you want to transport large amounts of data between two processes with low latency you are way better off using a plain ringbuffer+sync protocol
or even just plain sockets, be it custom or TCP

Ok, we'll switch to using sockets. Great. Now every application and it's dog has a slightly different protocol, and it's nearly impossible to interconnect things that were not designed specifically to interconnect. And throw security out the window too, because now every damn application handles that differently.

Or we could just use kdbus, which is now more capable of handling large amounts of data than dbus ever was.

[psychoticmeow]

i think educating programmers is more important then making things easier for people who do not want to learn

This is like arguing that we should be writing things in assembler instead of making things easier.

things like ring buffers are not really complex, it's just the general idea that they are that frightens people away from learning them

And when dealing with the scenarios that dbus deals with this is applicable how?

[interested]

this is dbus
it is complex

No, the _protocol_ isn't complex. The reference implemenation may be because it was made to run on Linux/Unix/BSD/Windows/Mac.

it was made to be a generic bus to make writing desktop applications easier
it was not made to transport audio or be used for real-time interactive processes

if you want to transport large amounts of data between two processes with low latency you are way better off using a plain ringbuffer+sync protocol
or even just plain sockets, be it custom or TCP

people want to use whatever they know how to use for everything
but that is not always the best solution
for example just because java is one of the more popular programming languages today does not mean we should design everything around java
so just because desktop app programmers know dbus well does not mean that it should be used for everything

i hope you can agree with this

Again, you are missing the point; your "solution" would never work like D-Bus unless you invent and duplicate D-Bus for your data channels. Your solution simply can't solve the problems that kdbus/D-Bus solves.

And again, if you try to add marshaling, broadcasting and message queues to your solution, you have in fact invented a new IPC that only works on Linux and isn't supported by a single piece of software.

kdbus on the other hand, will instantly upgrade the entire D-Bus-using Linux userland to a new kernel IPC, without anybody needing to change a line of code.

The kdbus solution also mean that Unix/BSD and non-systemd distros aren't left behind by systemd-distros migrating to a new IPC.

[gens]

Reading your comments sound like you are uninterested to read the post that responded to your question as long they don't fit your own view. In that case, it means you wasted those people time honestly.

the post was about using dbus for performance sensitive things
making it usable for everything and making everything use it

to quote
"And that really is the whole point and philosophy behind kdbus; make complex things easy by abstracting the complexity away with an easy to use API, and make developing fast with libs and features."

that is what i was replying to with the "jack of all trades, master of none" argument
i think educating programmers is more important then making things easier for people who do not want to learn
things like ring buffers are not really complex, it's just the general idea that they are that frightens people away from learning them


do you have anything to add ?