[Box Backup] Another wish for 2011

Chris Wilson chris at qwirx.com
Tue Jan 25 23:56:58 GMT 2011


Hi Leif,

On Tue, 25 Jan 2011, Leif Linderstam wrote:

> Thanks for your quick response.

No problem :)

> I saw your other email with the protocol definition. That is enough for 
> the time being, although a Wiki entry would be nice in the long run :)

I am working on it (offline now :)

>>> The current approach in a way is ad hoc
>>
>> It is intended to be thus, to some extent, to allow us to extend the 
>> protocol in future. Box Backup is not finished software and its 
>> protocol is not defined in any RFC yet, and may never be.
>
> My thinking with a tagged protocol was to make it easier to extend, but 
> I understand that among all things to prioritize between this would not 
> come high even if thought of as a good idea.

I just wanted to check what you meant by a "tagged" protocol? Every 
message in the Box Backup protocol (after the handshake) is "tagged" with 
a message type code and a length. If we really wanted to, we could define 
a new command, and either delete or deprecate (and maintain support for) 
the old command to maintain backwards compatibility. Is that what you mean 
by "tagged"?

>>> because it depends on what the compiler happens to generate.
>>
>> This however is clearly a bug.
>
> Yes it is a bug in the compiler (which is what I think you meant)

Actually I meant it's a bug in Box Backup. It should do whatever is 
necessary to maintain the wire protocol compatibility in the face of 
compiler differences. If it fails to do so then I consider that a bug in 
Box, not a compiler bug.

>> Creating a protocol which is fully backwards and forwards compatible is an
>> immense overhead to maintain, witness the Win32 API. There is limited
>
> Yes, but I still believe that a system like this at least has to handle 
> two consecutive protocol versions in one direction unless it only is 
> used in fairly small setting where all involved machines can reasonably 
> be updated at the same time. Either the server or the client can handle 
> two versions, but I guess that the best would be for the server to do so 
> because it would then be able to spot any clients that has not yet been 
> updated to the latest version. But of course all of this is just my 
> opinion, just as with the rest of the comments :)

I agree in theory. It would be great if we had regression testing against 
the previous client version in new releases of Box Backup. We just don't 
have the infrastructure in place to do it at present.

>>> A tagged protocol can be made so that even if the receiver does not 
>>> understand a particular tag it can still skip over it and continue 
>>> with the rest of the message. This would make the system more robust 
>>> to small changes in the protocol.
>>
>> That is currently possible, if the client uses a command that the 
>> server does not understand and correctly interprets and handles the 
>> server's error response.
>
> I haven't looked into the code throughly enough to quite understand your 
> comment. Can the client do something more intelligible than issue an 
> error message that the communication failed?

Yes, the client can (in theory) detect an error response, and rather than 
just aborting the connection, it could retry the command with a different 
set of parameters, or try the older (deprecated) command instead. However, 
I'm not aware of a client that currently does so.

> I was thinking more about being able to skip single fields than whole 
> messages. For example, if a directory listing is requested the server 
> might send answer messages with more information elements than the 
> client knows about, but the client can still read the elements it does 
> know about and skip the rest. E.g. if the client knows about file name 
> and size, but not permissions, it can still print some information.

This is possible in some cases, again in theory, but I think the current 
clients would simply fail (throw an exception) if they received a 
structure with the wrong size, out of paranoia. This is a backup product 
after all, and we don't currently have the infrastructure to perform the 
kinds of regression testing that we would like to have before promising 
backwards compatibility of a newer server against an older client version.

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <chris+sig at qwirx.com> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |



More information about the Boxbackup mailing list