Added clarifications to the draft.

diff --git a/doc/swift-protocol.txt b/doc/swift-protocol.txt
index cc3f88f..11597de 100644 (file)
--- 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