bzr.dev <-> bzr.dev network api break

[Andrew Bennetts]

Robert Collins wrote:
> On Fri, 2008-01-18 at 16:10 -0600, Matthew D. Fuller wrote:
[...]
> > Seen in pull/update against a 1.0 server (with revs to pull; a pull
> > just changing head rev doesn't trigger it):
> > 
> >     bzr: ERROR: Generic bzr smart protocol error: Generic bzr smart protocol error: bad request '115'
> >     /home/fullermd/src/bzr/bzr.dev/bzrlib/lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.remote.RemoteSSHTransport url=bzr+ssh://somehost/some/path/.bzr/repository/>) was not explicitly unlocked
> > 
> > 
> > bzr.dev:3191 works, but 3192 ("(robertc) Reduce traffic when
> > requesting revision streams [...]") fails.
> 
> I think this is a bug in 1.0; Andrew?

I'm not sure that it's a bug in 1.0... I don't think the current protocol
definition gives it much of a chance to behave any other way.

> (My theory is the server reads an unknown request, doesn't read the body
> from it, and then barfs on the body).

I think that's what's happening too.  Unfortunately, the only way the server can
know if it should read a body is if it recognises the verb, and knows that that
verb would have a body.  I suppose theoretically it could peek ahead and see if
the next bytes “look like” a body or the start of a new request, but that would
be pretty ugly, and besides the existing versions don't do it, so it won't help
interoperability to implement it now.

We should make the next revision of the wire protocol explicitly encode in a
request if there is a body, so that even if the server doesn't recognise the
request it can consume all the bytes from it and get the connection back to a
state where it can receive more requests.

Perhaps we should just do this bump now, there's a couple of things accumulating
that we could fix in a new protocol version:

  * reliably consume bodies of unrecognised requests (and responses)
  * an explicit, clean way for a server to signal to the client that a request
    verb is unrecognised
  * sending client version information

Otherwise the only options for interoperability of bzr.dev with 1.1 and earlier
are requiring people to upgrade their server to use bzr 1.2 clients (in which
case a protocol version bump would be nice anyway), or disconnecting and
reconnecting when an request with a body gets an unrecognised response.

So, I think we should:

  * create a protocol version 3 that can cope with this situation safely, and
  * teach the client to fallback to methods that don't require sending request
    bodies if the protocol version < 3.

-Andrew.