D-BUS spec - comments on wire protocol

[Havoc Pennington]

On Fri, 2005-01-21 at 11:31 -0500, David A. Wheeler wrote:
> However, I suggest some changes in the header:
> * The FIRST byte should be the "Major protocol version"
>    (currently the FOURTH byte).  Many protocols always
>   start with a major protocol version number (e.g., IP),
>   so that if you find out you need to change it massively
>   later, you can do so.  Otherwise, you have the weird
>   case of "looking in byte 4 to see what byte 1 means".
>   I think "major protocol version" values are important,
>   because they give you built-in flexibility.. if later on you
>   find out there's a critical problem, you can create a
>   new format without forcing an unworkable "flag day"
>   on all users.
> * The SECOND byte should probably be endianness,
>    (early in case there are problems),
>   THIRD message type, FOURTH for flags.
>    Endian-ness is early so that the rest can be correctly
>    interpreted, and message-type before flags so that
>    the flags' meanings will make sense (in case they
>    depend on the message type).

In practice I'm not sure this makes a lot of difference, but you're
probably right it's slightly cleaner.

I don't really like the protocol version per-message; it should probably
be negotiated in the auth protocol.

> * Wouldn't it be better if "endianness" was a simple bit,
>   say the LSB of the endianness byte?
>   That way, if you run out of room in the "flags", you
>   have some spare bits.

I suppose so, sure, though you have to require people to mask out all
the other bits when reading this byte to allow adding flags.

> I'm not excited that implementations are FORBIDDEN to
> accept arrays larger than 2^26 bytes.  Clearly sending a document
> is NOT the expected use of D-BUS, but forceably creating arbitrary
> limits is often not a great idea unless there's a security issue,
> which isn't suggested here.  I suggest changing
> the array text to this: "Implementations and users SHOULD not
> send arrays larger than 2^26 bytes, and implementations MAY refuse
> to accept arrays larger than 2^26 bytes."

But how does an app "adapt" to that variable limit? It should be
hardcoded until we answer that question. I don't think "try to send a
huge block of data and get an error and retry" is a good answer.

I think the answer is that the app has to request the current limit from
the peer, and then chunk the data into multiple pieces below the limit.
Given that, it has to be hardcoded until there's a way to request the
current limit (dbus_connection_get_max_array_size() in effect).

To me a better approach than allowing huge arrays would be some kind of
standard support for streams.

Another issue here is that testing INT_MAX arrays is both very necessary
(they are pretty likely to break the code) and very inefficient and
painful.

> P.S.: Is something wrong with the mailing list server? I see your
> personal replies, but not the mailing list copies, and messages seem to
> not be posted to the Archives.

Yes, it appears to be wedged. Maybe someone will notice soon and fix
it. ;-)

Havoc