more lapses

diff --git a/doc/draft-ietf-ppsp-grishchenko-swift.nroff b/doc/draft-ietf-ppsp-grishchenko-swift.nroff
index 8e84680..1461f89 100644 (file)
--- a/doc/draft-ietf-ppsp-grishchenko-swift.nroff
+++ b/doc/draft-ietf-ppsp-grishchenko-swift.nroff
@@ -476,6 +476,7 @@ message (type 7) to announce the fact:
 .ti 0\r
 4.5.  Peer exchange and NAT hole punching\r
 \r
+.fi\r
 Peer exchange messages are common for many peer-to-peer protocols. By exchanging peer IP addresses in gossip fashion, peers relieve central coordinating entities (the trackers) from unnecessary work. Following the example of BitTorrent, swift features two types of PEX messages: "peer connected" (type 5) and "peer disconnected" (type 6). Peers are represented as IPv4 address-port pairs:\r
 .nf\r
 05 7F000000 1F40\r
@@ -563,7 +564,7 @@ The most theoretically correct way is to run swift on top of IP, as another tran
 .ti 0\r
 5.2.  UDP\r
 \r
-.nf\r
+.fi\r
 Currently, swift-over-UDP is the default deployment option. Effectively, UDP allows to use IP with minimal overhead, it also allows userspace implementations.\r
 Besides the classic 1KB packet scenario, the bin numbering allows to use swift over Jumbo frames/datagrams. Both data and acknowledgments may use e.g. 8KB packets instead of "standard" 1KB. Hashing scheme stays the same.\r
 Using swift with 512 or 256-byte packets is theoretically possible with 64-bit byte-precise bin numbers, but IP fragmentation might be a better method to achieve the same result.\r

diff --git a/doc/draft-ietf-ppsp-grishchenko-swift.txt b/doc/draft-ietf-ppsp-grishchenko-swift.txt
index b9dfe15..72f3b44 100644 (file)
--- a/doc/draft-ietf-ppsp-grishchenko-swift.txt
+++ b/doc/draft-ietf-ppsp-grishchenko-swift.txt
@@ -636,7 +636,12 @@ Internet-Draft                   swift                        April 2010
 \r
 4.5.  Peer exchange and NAT hole punching\r
 \r
-   Peer exchange messages are common for many peer-to-peer protocols. By exchanging peer IP addresses in gossip fashion, peers relieve central coordinating entities (the trackers) from unnecessary work. Following the example of BitTorrent, swift features two types of PEX messages: "peer connected" (type 5) and "peer disconnected" (type 6). Peers are represented as IPv4 address-port pairs:\r
+   Peer exchange messages are common for many peer-to-peer protocols. By\r
+   exchanging peer IP addresses in gossip fashion, peers relieve central\r
+   coordinating entities (the trackers) from unnecessary work. Following\r
+   the example of BitTorrent, swift features two types of PEX messages:\r
+   "peer connected" (type 5) and "peer disconnected" (type 6). Peers are\r
+   represented as IPv4 address-port pairs:\r
    05 7F000000 1F40\r
    (connected to 127.0.0.1:8000)\r
 \r
@@ -661,11 +666,6 @@ Internet-Draft                   swift                        April 2010
    certain ranges of data (e.g. BitTorrent's REQUEST message), live\r
    streaming protocols quite often do without to save round trips.\r
    Explicit requests are often needed for security purposes; consider\r
-   that BitTorrent can only verify hashes of complete pieces that might\r
-   consist of multiple blocks requested from many peers. As swift has no\r
-   such implications, it is supposed to work both ways. Namely, a peer\r
-   SHOULD send out requested pieces, while it also may send some other\r
-   data in case it runs out of requests or on some other reason. To\r
  \r
 \r
 \r
@@ -674,6 +674,11 @@ Grishchenko             Expires October 12, 2010               [Page 12]
 Internet-Draft                   swift                        April 2010\r
 \r
 \r
+   that BitTorrent can only verify hashes of complete pieces that might\r
+   consist of multiple blocks requested from many peers. As swift has no\r
+   such implications, it is supposed to work both ways. Namely, a peer\r
+   SHOULD send out requested pieces, while it also may send some other\r
+   data in case it runs out of requests or on some other reason. To\r
    emphasize that, request messages are named HINTs; their only purpose\r
    is to coordinate peers and to avoid unnecessary data retransmission.\r
    A peer SHOULD to process HINTs sequentially. HINT message type is 8.\r
@@ -717,11 +722,6 @@ Internet-Draft                   swift                        April 2010
    implementation for all peers.\r
 \r
 \r
-5.2.  UDP\r
-\r
-   Currently, swift-over-UDP is the default deployment option. Effectively, UDP allows to use IP with minimal overhead, it also allows userspace implementations.\r
-   Besides the classic 1KB packet scenario, the bin numbering allows to use swift over Jumbo frames/datagrams. Both data and acknowledgments may use e.g. 8KB packets instead of "standard" 1KB. Hashing scheme stays the same.\r
-   Using swift with 512 or 256-byte packets is theoretically possible with 64-bit byte-precise bin numbers, but IP fragmentation might be a better method to achieve the same result.\r
  \r
 \r
 \r
@@ -730,6 +730,19 @@ Grishchenko             Expires October 12, 2010               [Page 13]
 Internet-Draft                   swift                        April 2010\r
 \r
 \r
+5.2.  UDP\r
+\r
+   Currently, swift-over-UDP is the default deployment option.\r
+   Effectively, UDP allows to use IP with minimal overhead, it also\r
+   allows userspace implementations. Besides the classic 1KB packet\r
+   scenario, the bin numbering allows to use swift over Jumbo\r
+   frames/datagrams. Both data and acknowledgments may use e.g. 8KB\r
+   packets instead of "standard" 1KB. Hashing scheme stays the same.\r
+   Using swift with 512 or 256-byte packets is theoretically possible\r
+   with 64-bit byte-precise bin numbers, but IP fragmentation might be a\r
+   better method to achieve the same result.\r
+\r
+\r
 5.3.  TCP\r
 \r
    If ran over TCP, the swift becomes functionally equivalent to\r
@@ -765,19 +778,6 @@ Internet-Draft                   swift                        April 2010
 \r
 \r
 \r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
  \r
 \r
 \r