6 ms·

It isn't ASCII only, and I don't even see where the author of this article got that idea. Read the spec instead of the article and you'll learn more: http://dbu

by hp 12y ago

It isn't ASCII only, and I don't even see where the author of this article got that idea. Read the spec instead of the article and you'll learn more: http://dbus.freedesktop.org/doc/dbus-specification.html http://dbus.freedesktop.org/doc/dbus-specification.html

riffraff 12y ago
the author got it from exactly that link, the exact text is the one reported in the article, just CTRL+F "the protocol is ASCII-only". I presume text was edited a few times in different places withou re-checking everything.
- hp 12y ago
  No. he's confusing the auth protocol with the dbus protocol.
  - riffraff 12y ago
    well, yes, but he's arguing that the documentation is bad, not that the dbus protocol doesn't exist. The phrasing "The text protocol described in this document" (sic) can not easily be interpreted as "the thing described in this section, but not in the rest of the document". I stand by my interpretation of incoherent editing.
  - brainsalad 12y ago
    "Immediately after connecting to the server, the client must send a single nul byte. This byte may be accompanied by credentials information on some operating systems that use sendmsg() with SCM_CREDS or SCM_CREDENTIALS to pass credentials over UNIX domain sockets. However, the nul byte must be sent even on other kinds of socket, and even on operating systems that do not require a byte to be sent in order to transmit credentials. The text protocol described in this document begins after the single nul byte. If the first byte received from the client is not a nul byte, the server may disconnect that client." Oh, technically the dbus auth handshake is defined as not being part of the dbus protocol. That's not convincing.
    - fmoralesc 12y ago
      If they are defined as separate protocols, then the argument that the spec is ridiculous because it contradicts itself on this point is based on a misunderstanding, whatever the merit (or demerit) for these things being separate protocols is.
krig 12y ago
Okay. From the spec: "D-Bus is low-overhead because it uses a binary protocol" - Alright, got it. It's binary. "The protocol is a line-based protocol, where each line ends with \r\n. Each line begins with an all-caps ASCII command name containing only the character range [A-Z_], a space, then any arguments for the command, then the \r\n ending the line. The protocol is case-sensitive. All bytes must be in the ASCII character set." Wait a second. This section describes a line-based ASCII protocol. Is this some other protocol? "A nul byte in any context other than the initial byte is an error; the protocol is ASCII-only." Ookay. So... it's ASCII only, except for the first byte? "Returns auditing data used by Solaris ADT, in an unspecified binary format. If you know what this means, please contribute documentation via the D-Bus bug tracking system." Oh, no, okay... unspecified binary format. THIS IS ACTUALLY IN THE "SPEC". Sorry for yelling. I lost it a bit there. Not quite as much as the authors of the dbus "specification", though.
- drdaeman 12y ago
  > A nul byte in any context other than the initial byte is an error Oh, just found this in the spec, too: "The marshalling formats for the string-like types all end with a single zero (NUL) byte"
  - fmoralesc 12y ago
    The first quote talks about the auth protocol, while the second talks about the DBus protocol proper.
- hp 12y ago
  Yes, there's an auth protocol before the actual dbus protocol - there are two protocols in the spec. I think that's what you are missing. Perhaps it's confusing but slow down and understand the tech before criticizing. It is not in fact an ASCII-only binary protocol. Other engineers do sometimes know what they are doing.
  - krig 12y ago
    Let me get this straight. To you, there is nothing wrong with embedding a separate ASCII protocol for authentication inside a binary protocol? Of course I realize that the quoted text about ascii-only describes a subset of the full protocol. To do this is ridiculous and bad engineering. I also note that you completely ignored "If you know what this means, please contribute documentation via the D-Bus bug tracking system." appearing in the specification. Seriously. This is not a specification. This is a poorly written description of an existing mess of a wire protocol. Other engineers clearly do not know what they are doing.

by hp 12y ago

riffraff 12y ago

the author got it from exactly that link, the exact text is the one reported in the article, just CTRL+F "the protocol is ASCII-only". I presume text was edited a few times in different places withou re-checking everything.

hp 12y ago
No. he's confusing the auth protocol with the dbus protocol.
- riffraff 12y ago
  well, yes, but he's arguing that the documentation is bad, not that the dbus protocol doesn't exist. The phrasing "The text protocol described in this document" (sic) can not easily be interpreted as "the thing described in this section, but not in the rest of the document". I stand by my interpretation of incoherent editing.
- brainsalad 12y ago
  "Immediately after connecting to the server, the client must send a single nul byte. This byte may be accompanied by credentials information on some operating systems that use sendmsg() with SCM_CREDS or SCM_CREDENTIALS to pass credentials over UNIX domain sockets. However, the nul byte must be sent even on other kinds of socket, and even on operating systems that do not require a byte to be sent in order to transmit credentials. The text protocol described in this document begins after the single nul byte. If the first byte received from the client is not a nul byte, the server may disconnect that client." Oh, technically the dbus auth handshake is defined as not being part of the dbus protocol. That's not convincing.
  - fmoralesc 12y ago
    If they are defined as separate protocols, then the argument that the spec is ridiculous because it contradicts itself on this point is based on a misunderstanding, whatever the merit (or demerit) for these things being separate protocols is.

krig 12y ago

Okay. From the spec: "D-Bus is low-overhead because it uses a binary protocol" - Alright, got it. It's binary. "The protocol is a line-based protocol, where each line ends with \r\n. Each line begins with an all-caps ASCII command name containing only the character range [A-Z_], a space, then any arguments for the command, then the \r\n ending the line. The protocol is case-sensitive. All bytes must be in the ASCII character set." Wait a second. This section describes a line-based ASCII protocol. Is this some other protocol? "A nul byte in any context other than the initial byte is an error; the protocol is ASCII-only." Ookay. So... it's ASCII only, except for the first byte? "Returns auditing data used by Solaris ADT, in an unspecified binary format. If you know what this means, please contribute documentation via the D-Bus bug tracking system." Oh, no, okay... unspecified binary format. THIS IS ACTUALLY IN THE "SPEC". Sorry for yelling. I lost it a bit there. Not quite as much as the authors of the dbus "specification", though.

drdaeman 12y ago
> A nul byte in any context other than the initial byte is an error Oh, just found this in the spec, too: "The marshalling formats for the string-like types all end with a single zero (NUL) byte"
- fmoralesc 12y ago
  The first quote talks about the auth protocol, while the second talks about the DBus protocol proper.
hp 12y ago
Yes, there's an auth protocol before the actual dbus protocol - there are two protocols in the spec. I think that's what you are missing. Perhaps it's confusing but slow down and understand the tech before criticizing. It is not in fact an ASCII-only binary protocol. Other engineers do sometimes know what they are doing.
- krig 12y ago
  Let me get this straight. To you, there is nothing wrong with embedding a separate ASCII protocol for authentication inside a binary protocol? Of course I realize that the quoted text about ascii-only describes a subset of the full protocol. To do this is ridiculous and bad engineering. I also note that you completely ignored "If you know what this means, please contribute documentation via the D-Bus bug tracking system." appearing in the specification. Seriously. This is not a specification. This is a poorly written description of an existing mess of a wire protocol. Other engineers clearly do not know what they are doing.