From ab6419fc313c6f1658177944e521e61b124c10db Mon Sep 17 00:00:00 2001 From: Victor Grishchenko Date: Wed, 27 Jan 2010 19:50:24 +0100 Subject: [PATCH] Added clarifications to the draft. --- doc/swift-protocol.txt | 51 ++++++++++++++++++++++++++++++++++++++---- 1 file changed, 47 insertions(+), 4 deletions(-) diff --git a/doc/swift-protocol.txt b/doc/swift-protocol.txt index cc3f88f..11597de 100644 --- a/doc/swift-protocol.txt +++ b/doc/swift-protocol.txt @@ -205,6 +205,15 @@ Table of Contents hex-like two char per byte notation is used to represent message formats. + A sender MUST always put a data message (type id 1) in the tail of + a datagram. Such message consists of type id, bin number (see Sec. + 4.3) and the actual data. Normally there is 1 kilobyte of data, + except the case when file size is not a multiple of 1024 bytes, so + the tail packet is somewhat shorter. Example: + 01 00000000 48656c6c6f20776f726c6421 + (This message accommodates an entire file: "Hello world!") + + 4.2. Handshake and multiplexing For the sake of simplicity, one transfer always deals with one file @@ -248,7 +257,8 @@ Table of Contents In general, no error codes or responses are used in the protocol; absence of any response indicates an error. Invalid messages are - discarded. + discarded. Explicit close of a channel is achieved by setting + channel number to zero by a handshake message: 00 00000000. Simple NAT hole punching [SNP] introduces the scenario when both parties of the handshake are initiators. To avoid creation of two @@ -495,7 +505,7 @@ Table of Contents 4.6. Congestion control - swift employs pluggable congestion control. In general, it is + Swift employs pluggable congestion control. In general, it is expected that servers would use TCP-like congestion control schemes such as classic AIMD or CUBIC [CUBIC]. End-user peers are expected to use weaker-than-TCP (least than best effort) congestion control, @@ -519,7 +529,21 @@ Table of Contents HINTs sequentially. HINT message type is 3. 03 00000009 (a peer requests fifth and sixth packets) + + +4.8. Subsetting of the protocol + As the same protocol is supposed to serve diverse usecases, + different peers may support different subsets of messages. The + supported subset SHOULD be signalled in the handshake packets. + Messages SWIFT_MSGTYPE_SENT (type 8) and SWIFT_MSGTYPE_RCVD (type + 9) serve exactly this purpose. They are followed with 32-bit + big-endian numbers with bits set to 1 at offsets corresponding + to supported message type ids. E.g. for a tracker peer which + receives only handshakes and (root) hashes, sends out handshakes + and PEX_ADD messages, those two messages will look like: + 08 00000021 09 00000011 + 5. Security Considerations @@ -531,12 +555,31 @@ Table of Contents 6.6. Extensibility -6.1.1. Different crypto/hashing schemes +6.1.1. 32 bit vs 64 bit + While in principle the protocol supports bigger (>1TB) files, all + the mentioned counters are 32-bit. It is an optimization as using + 64-bit numbers in the on-wire packet format may cost ~2% overhead. + 64-bit version of every message has typeid of 64+t, e.g. typeid + 68 for 64-bit hash message. E.g. + 44 000000000000000E 01234567890ABCDEF1234567890ABCDEF1234567 + Once 32-bit message is supported, 64-bit version MUST be + understood as well. + 6.1.2. IPv6 + IPv6 versions of PEX messages use the same 64+t shift as in 6.1.1. + 6.1.3. Congestion control algorithms 6.1.4. Piece picking algorithms 6.1.5. Reciprocity algorithms -6.1.6. 32 bit vs 64 bit +6.1.6. Different crypto/hashing schemes + Once a flavour of swift will need to use a different crypto scheme + (e.g. SHA-256), a message should be allocated for that. As the + root hash is supplied in the handshake message, the crypto scheme + in use will be known from the very beginning. As the root hash is + the identifier, different schemes of crypto cannot be mixed in the + same swarms, but different swarms may distribute the same content + using different crypto. + References -- 2.20.1