From 0368c89d5733bcf5afc6854a71f10696420ee0df Mon Sep 17 00:00:00 2001 From: Victor Grishchenko Date: Wed, 27 Jan 2010 18:25:53 +0100 Subject: [PATCH] Merged doc file fixes by Sasha --- doc/swift-protocol.txt | 24 +++++++++++++----------- swift.h | 3 ++- 2 files changed, 15 insertions(+), 12 deletions(-) diff --git a/doc/swift-protocol.txt b/doc/swift-protocol.txt index 42f1afb..cc3f88f 100644 --- a/doc/swift-protocol.txt +++ b/doc/swift-protocol.txt @@ -392,7 +392,7 @@ Table of Contents have three peaks, bin numbers 3, 9, 12. Thus, once a newcomer joins a swarm, the first peer sending him data prepends it with peak hashes; the newcomer checks them against - the root hash (see Sec 4.2.2). + the root hash (see Sec 4.4.2). 04 00000003 1234567890ABCDEF1234567890ABCDEF12345678 04 00000009 234567890ABCDEF1234567890ABCDEF123456789 @@ -405,13 +405,13 @@ Table of Contents In the case of static file download a transfer is bootstrapped with a root hash. The root hash corresponds to the root bin covering the entire 2**63 KB data range. Every hash in the tree is defined - in the usual way, as a SHA-1 hash of a concatenation of two - lower-level SHA-1 hashes, corresponding to left and right data + in the usual way, as a SHA1 hash of a concatenation of two + lower-level SHA1 hashes, corresponding to left and right data half-ranges resp. For example, hash_1 = SHA1 (hash_0+hash_2) where + stands for concatenation and hash_i stands for Merkle hash of the bin number i. Obviously, that does not hold for the - base-layer hashes, which are normal SHA-1 hashes over 1KB data + base-layer hashes, which are normal SHA1 hashes over 1KB data ranges ("packets"), except probably for the tail packet, which might have less than 1KB of data. The normal recursive formula does not apply to empty bins, i.e. bins that have no data absolutely; @@ -438,9 +438,11 @@ Table of Contents anchors for building uncle chains during the transmission (as the root hash is too high in the sky). A newcomer peer MAY signal it already has peak hashes by acknowledging any bin, even empty one: + 02 FFFFFFFF - Otherwise, the first of the senders bootstraps him with all the - peak hashes. + + Otherwise, the first of the senders SHOULD bootstrap him with all + the peak hashes. 4.4.3. Hash trees for streams @@ -454,14 +456,14 @@ Table of Contents data range the receiver has peak hashes for and to prepend the data and the uncle hashes with the necessary (signed) peak hashes. Except for the fact that the set of peak hashes changes with the - time, other parts of the algorithm work as described in 4.4.3 As we + time, other parts of the algorithm work as described in 4.4.2 As we see, in both cases data length is not known on advance, bit derived on-the-go from the peak hashes. Suppose, our 7KB stream extended to - another kilobyte. Thus, now hash 15 becomes the only peak hash, - eating hashes 7, 10, 11 and the source sends out a signed peak hash + another kilobyte. Thus, now hash 7 becomes the only peak hash, + eating hashes 3, 9, 12 and the source sends out a signed peak hash message (type 7) to announce the fact: - 07 0000000F 1234567890ABCDEF1234567890ABCDEF12345678 SOME-SIGN-HERE + 07 00000007 1234567890ABCDEF1234567890ABCDEF12345678 SOME-SIGN-HERE 4.5. Peer exchange and NAT hole punching @@ -521,7 +523,7 @@ Table of Contents 5. Security Considerations - simplify as possible (e.g. no buffer overruns) Still, resource, + Simplify as possible (e.g. no buffer overruns). Still, resource, membership subverting [] for DDoS Thus, implementation MUST at least rate-limit activity to untested destinations. E.g. 4 attempts a second: million peers, 1Gb/sec, amplification ratio 4. diff --git a/swift.h b/swift.h index 8c65dd3..0dc3240 100644 --- a/swift.h +++ b/swift.h @@ -120,7 +120,8 @@ namespace swift { P2TP_HASH = 4, P2TP_PEX_ADD = 5, P2TP_PEX_RM = 6, - P2TP_MESSAGE_COUNT = 7 + P2TP_SIGNED_HASH = 7, + P2TP_MESSAGE_COUNT = 8 } messageid_t; class PiecePicker; -- 2.20.1