/brz/remove-bazaar

================

Network Protocol

================

:Date: 2007-09-03

.. contents::

Overview

========

The smart protocol provides a way to send a requests and corresponding

responses to communicate with a remote bzr process.

Layering

========

Medium

------

At the bottom level there is either a socket, pipes, or an HTTP

request/response.  We call this layer the *medium*.  It is responsible for

carrying bytes between a client and server.  For sockets, we have the idea

that you have multiple requests and get a read error because the other

side did shutdown.  For pipes we have read pipe which will have a zero

read which marks end-of-file.  For HTTP server environment there is no

end-of-stream because each request coming into the server is independent.

So we need a wrapper around pipes and sockets to seperate out requests

from substrate and this will give us a single model which is consistent

for HTTP, sockets and pipes.

Protocol

--------

On top of the medium is the *protocol*.  This is the layer that

deserialises bytes into the structured data that requests and responses

consist of.

Request/Response processing

---------------------------

On top of the protocol is the logic for processing requests (on the

server) or responses (on the client).

Server-side

-----------

Sketch::

 MEDIUM  (factory for protocol, reads bytes & pushes to protocol,

          uses protocol to detect end-of-request, sends written

          bytes to client) e.g. socket, pipe, HTTP request handler.

  ^

  | bytes.

  v

 PROTOCOL(serialization, deserialization)  accepts bytes for one

          request, decodes according to internal state, pushes

          structured data to handler.  accepts structured data from

          handler and encodes and writes to the medium.  factory for

          handler.

  ^

  | structured data

  v

 HANDLER  (domain logic) accepts structured data, operates state

          machine until the request can be satisfied,

          sends structured data to the protocol.

Request handlers are registered in the `bzrlib.smart.request` module.

Client-side

-----------

Sketch::

 CLIENT   domain logic, accepts domain requests, generated structured

          data, reads structured data from responses and turns into

          domain data.  Sends structured data to the protocol.

          Operates state machines until the request can be delivered

          (e.g. reading from a bundle generated in bzrlib to deliver a

          complete request).

          Possibly this should just be RemoteBzrDir, RemoteTransport,

          ...

  ^

  | structured data

  v

 PROTOCOL  (serialization, deserialization)  accepts structured data for one

          request, encodes and writes to the medium.  Reads bytes from the

          medium, decodes and allows the client to read structured data.

  ^

  | bytes.

  v

 MEDIUM  (accepts bytes from the protocol & delivers to the remote server.

          Allows the potocol to read bytes e.g. socket, pipe, HTTP request.

The domain logic is in `bzrlib.remote`: `RemoteBzrDir`, `RemoteBranch`,

and so on.

There is also an plain file-level transport that calls remote methods to

manipulate files on the server in `bzrlib.transport.remote`.

Protocol description

====================

Version one

-----------

Version one of the protocol (for requests and responses) is described by::

  REQUEST := MESSAGE_V1

  RESPONSE := MESSAGE_V1

  MESSAGE_V1 := ARGS BODY

  ARGS := ARG [MORE_ARGS] NEWLINE

  MORE_ARGS := SEP ARG [MORE_ARGS]

  SEP := 0x01

  BODY := LENGTH NEWLINE BODY_BYTES TRAILER

  LENGTH := decimal integer

  TRAILER := "done" NEWLINE

That is, a tuple of arguments separated by Ctrl-A and terminated with a

newline, followed by length prefixed body with a constant trailer.  Note

that although arguments are not 8-bit safe (they cannot include 0x01 or

0x0a bytes without breaking the protocol encoding), the body is.

Version two

-----------

Version two of the request protocol is::

  REQUEST_V2 := "bzr request 2" NEWLINE MESSAGE_V2

Version two of the response protocol is::

  RESPONSE_V2 := "bzr request 2" NEWLINE MESSAGE_V2

Future versions should follow this structure, like version two does::

  FUTURE_MESSAGE := VERSION_STRING NEWLINE REST_OF_MESSAGE

This is so that clients and servers can read bytes up to the first newline

byte to determine what version a message is.

For compatibility will all versions (past and future) of bzr clients,

servers that receive a request in an unknown protocol version should

respond with a single-line error terminated with 0x0a (NEWLINE), rather

than structured response prefixed with a version string.

Version two of the message protocol is::

  MESSAGE_V2 := ARGS BODY

  BODY_V2 := BODY | STREAMED_BODY

That is, a version one length-prefixed body, or a version two streamed

body.

A streamed body looks a lot like HTTP's chunked encoding::

  STREAMED_BODY := "chunked" NEWLINE CHUNKS TERMINATOR

  CHUNKS := CHUNK [CHUNKS]

  CHUNK := CHUNK_LENGTH CHUNK_CONTENT

  CHUNK_LENGTH := HEX_DIGITS NEWLINE

  CHUNK_CONTENT := bytes

  TERMINATOR := SUCCESS_TERMINATOR | ERROR_TERMINATOR

  SUCCESS_TERMINATOR := 'END' NEWLINE

  ERROR_TERMINATOR := 'ERR' NEWLINE CHUNKS SUCCESS_TERMINATOR

That is, the body consists of a series of chunks.  Each chunk starts with

a length prefix in hexadecimal digits, followed by an ASCII newline byte.

The end of the body is signaled by 'END\\n', or by 'ERR\\n' followed by

error args, one per chunk.  Note that this allows an 8-bit clean error

response.

A streamed body starts with the string "chunked" so that legacy clients

and servers will not mistake the first chunk as the start of a version one

body.

Software versions

-----------------

Version 1 of the protocol was introduced in Bazaar 0.11.

Version 2 was introduced in Bazaar 0.16.

Paths

=====

Paths are passed across the network.  The client needs to see a namespace

that includes any repository that might need to be referenced, and the

client needs to know about a root directory beyond which it cannot ascend.

Servers run over ssh will typically want to be able to access any path the

user can access.  Public servers on the other hand (which might be over

http, ssh or tcp) will typically want to restrict access to only a

particular directory and its children, so will want to do a software

virtual root at that level.  In other words they'll want to rewrite

incoming paths to be under that level (and prevent escaping using ../

tricks.)

URLs that include ~ should probably be passed across to the server

verbatim and the server can expand them.  This will proably not be

meaningful when limited to a directory?

Requests

========

The available request methods are registered in `bzrlib.smart.request`.

..

   vim: ft=rst tw=74 ai