mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

version the P2P protocol

Browse source 
Unfortunately ReceiveMessage didn't handle unknown messages the way it
was documented to; client sending VERSION would cause the server to
return an ERROR and hang up. Fixed that, but old releases of git-annex
use the P2P protocol for tor and will still have that behavior.

So, version is not negotiated for Remote.P2P connections, only for
Remote.Git connections, which will support VERSION from their first
release. There will need to be a later flag day to change Remote.P2P;
left a commented out line that is the only thing that will need to be
changed then.

Version 1 of the P2P protocol is not implemented yet, but updated
the docs for the DATA change that will be allowed by that version.

This commit was sponsored by Jeff Goeke-Smith on Patreon.
This commit is contained in:
Joey Hess 2018-03-12 13:43:19 -04:00
parent 5ae103e09a
commit c81768d425
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
11 changed files with 201 additions and 88 deletions
Download patch file Download diff file Expand all files Collapse all files

61
doc/design/p2p_protocol.mdwn
View file

@ -6,9 +6,23 @@ serializations are also possible. The line-based serialization is spoken
by [[git-annex-shell], and by git-annex over tor.
One peer is known as the client, and is the peer that initiates the
connection. The other peer is known as the server, and is the peer that the
client connects to. It's possible for two connections to be run at the same
time between the same two peers, in different directions.
connection and sends commands. The other peer is known as the server, and
is the peer that the client connects to. It's possible for two connections
to be run at the same time between the same two peers, in different
directions.
## Errors
Either the client or the server may send an error message at any
time.
When the client sends an ERROR, the server will close the connection.
If the server sends an ERROR in response to the client's
request, the connection will remain open, and the client can make
another request.
ERROR this repository is read-only; write access denied
## Authentication
@ -16,7 +30,7 @@ The protocol genernally starts with authentication. However, if
authentication already occurs on another layer, as is the case with
git-annex-shell, authentication will be skipped.
The client starts by sending an authentication to the server,
The client starts by sending an authentication command to the server,
along with its UUID. The AuthToken is some arbitrary token that has been
agreed upon beforehand.
@ -33,18 +47,29 @@ Note that authentication does not guarantee that the client is talking to
who they expect to be talking to. This, and encryption of the connection,
are handled at a lower level.
## Errors
## Protocol version
Either the client or the server may send an error message at any
time.
The default protocol version is 0. The client can choose to
negotiate a new version with the server. This must come after
any authentication.
When the client sends an ERROR, the server will close the connection.
The client sends the highest protocol version it supports:
If the server sends an ERROR in response to the client's
request, the connection will remain open, and the client can make
another request.
VERSION 2
ERROR this repository is read-only; write access denied
The server responds with the highest protocol version it supports
that is less than or equal to the version the client sent:
VERSION 1
Now both client and server should use version 1.
(Note that old versions of git-annex, which speak the P2P protocol
over tor, don't support this, and attempting to negotiate a version
will cause the server to hang up the connection. To deal with this
historical bug, the version is not currently negotiated when using the
protocol over tor. At some point in the future, when all peers can be
assumed to be upgraded, this will be changed.)
## Binary data
@ -54,11 +79,21 @@ on its own line, followed by a newline and the binary data.
The Len value tells how many bytes of data to read.
DATA 3
foo
foo1
Note that there is no newline after the binary data; the next protocol
message will come immediately after it.
In protocol version 1 and higher, the binary data is suffixed with one
additional byte. Normally that is "1". "0" is used to indicate when the
file being transferred changed content while it was being sent
(eg, it was unlocked and got edited). In protocol version 0, this
additional byte is not sent.
If the sender finds itself unable to send as many bytes of data as it
promised (perhaps because a file got truncated while it was being sent),
its only option is to close the protocol connection.
## Checking if content is present
To check if a key is currently present on the server, the client sends: