What to do about HPSS protocol backwards compatibility for faster push?

Michael Hudson michael.hudson at canonical.com
Wed Oct 17 19:28:37 BST 2007


Andrew Bennetts wrote:
> As the smart server protocol changes, we need to make sure that different
> versions of the client and server can interoperate.  In many cases this easy: if
> new versions of the server supports older request methods, then older clients
> will continue to work.  Similarly, new versions of the client can often support
> older servers at minimal cost, by simply trying a request, and if the server
> doesn't recognise it, downgrade to something else.  The cost is one wasted
> roundtrip, a bit of fairly simple fallback logic in the client, and keeping the
> old request logic in the client and server.
>
> If the request is large (e.g. pushing 10MB container of revision data), then
> this isn't so good.  Sending a 10MB request just to get back a “sorry, I don't
> understand” response is going to be pretty slow.  What should we do about this?
>
> The specific case is I'm thinking of is that I want to implement a smart method
> to add a set of revisions to a repository (like the recently added method to
> retrieve a set of revisions).  Some options:
>
>   1) always try the large request, and then fallback.
>   2) always try the large request, and then fallback, but also warn the user
>      that they should upgrade the server to get much better performance.
>   3) send a “do you support request X?” request first (possibly integrate this
>      into the existing “hello” request).
>   4) add a configuration option to locations.conf so that users can turn off
>      this feature for known-old servers.
>   5) add a configuration option to the client to enable it (and have the feature
>      by off by default).
>
> I'm thinking I'll probably do 2 and perhaps also 4 (default to trying the large
> request, warn the user if the server is too old to support fast pushes, and
> allow the user to configure their client to avoid using this method if they
> know a server is too old).  The warnings from 2 might be a little annoying if
> you don't control the server-side, but in combination with 4 you'd be able to
> turn them off.  And people should be encouraged to upgrade to faster, better
> versions of bzr :)
>
> I don't much like 3, as I'd rather keep the protocol stateless, and it means
> unavoidable roundtrips for no actual work.  I don't like 5, because I'd like new
> clients and servers to be fast by default.  Hence my current preference for 2
> (plus 4).
>
> Does anyone have any comments, or other suggestions?
>   

You could have the client try to upload a small number of revisions in 
the first request, then if that works chuck everything over the wire.  
This means the client would have to keep track of some state, but it 
keeps it out of the protocol...

Cheers,
mwh



More information about the bazaar mailing list