*** empty log message ***

Rev: src/rsync/checksum.c:1.3
Rev: src/rsync/generate.c:1.3
Rev: src/rsync/protocol.txt:1.2
Rev: src/rsync/rsync.h:1.4

src/rsync/checksum.c

@@ -21,7 +21,7 @@
  *   b_k = \sum_0^k (l-i) x_i
  *
  * But in fact, we don't calculate all b_k, only the final
- * value b_{l-1}, and we have the identity (by changing order of summation(
+ * value b_{l-1}, and we have the identity (by changing order of summation)
  *
  *   b_{l-1} = \sum_0^{l-1} (l-i) x_i = \sum_0^{l-1} a_i
  *

src/rsync/generate.c

@@ -48,20 +48,7 @@ rsync_output_block(struct rsync_generate_state *s)
   rsync_init_block(s);
 }
 
-/* Update checksums.
- *
- * For input x_i, i = 0, ..., l-1, we calculate (modulo 2^16)
- *
- *   a_k = \sum_0^k x_i,
- *   b_k = \sum_0^k (l-i) x_i
- *
- * But in fact, we don't calculate all b_k, only the final
- * value b_{l-1}, and we have the identity (by changing order of summation(
- *
- *   b_{l-1} = \sum_0^{l-1} (l-i) x_i = \sum_0^{l-1} a_i
- *
- * So we keep track of the numbers c_k = \sum_0^k a_k rather than b_k.
- */
+/* Update checksums. */
 
 static void
 rsync_update(struct rsync_generate_state *s,
@@ -81,9 +68,10 @@ rsync_update(struct rsync_generate_state *s,
 
 #define DONE (s->offset == s->total_length)
 
-int rsync_generate(struct rsync_generate_state *s)
+int
+rsync_generate(struct rsync_generate_state *s)
 {
-  /* Have we maid any progress? */
+  /* Have we made any progress? */
   int progress = 0;
   
   for (;;)
@@ -110,7 +98,7 @@ int rsync_generate(struct rsync_generate_state *s)
 	    }
 	}
       if (!s->avail_out && s->buf_length)
-	/* We have buffered date, but no output space */
+	/* We have buffered data, but no output space */
 	return progress ? RSYNC_PROGRESS : RSYNC_BUF_ERROR;
 
       /* Here, the internal buffer should be flushed. */

src/rsync/protocol.txt

 I think it is a good idea to chop the rsync protocol into orthogonal
 parts. One part takes care of transport issues; i.e. version
-negotiaon, authentication, compression. The other does the actual
-data transfer insode a transport channel, and it doesn't have to care
+negotiation, authentication, compression. The other does the actual
+data transfer inside a transport channel, and it doesn't have to care
 about transport issues.
 
-Through out this document, "receiver" is the party that wants to
-reconstruct a copy of a file at the other pary, the "sender".
+Throughout this document, "receiver" is the party that wants to
+reconstruct a copy of a file at the other party, the "sender".
 
 The data in the several phases is represented as follows:
 
-Checksums sent from receiver and sender are represented as follows:
+Checksums sent from receiver to sender are represented as follows:
 
 First
 
-  4 octets, number of blocks
+  4 octets, number of blocks (including any final, small, block)
   4 octets, block size
-  4 octets, total size % blocksize, i.e. 0 or size of the final block
+  4 octets, total size % block size, i.e. 0 or size of the final block
 
 Next, a sequence of
 
   4 octets of rolling checksum
  16 octets md5 checksum
 
-In rsync-2.4.1 md4 is used rather than md5. As the length header is
-sent first, the file length must be known in advance.
+computed for each block. In rsync-2.4.1 md4 is used rather than md5.
+As the length header is sent first, the file length must be known in
+advance.
 
 Next, the sender transmits the information needed to reconstruct the
 file. The stream consists of a series of "tokens". Either
@@ -37,7 +38,7 @@ or
 
 or
 
-  4 octets, value n, MSB set. Let i = -(n + 1) == ~n (one's complent).
+  4 octets, value n, MSB set. Let i = ~n (one's complent).
                               Then insert block i into the file.
 
 (in rsync-2.4.1, the last form is more complicated; it refers to the
@@ -57,17 +58,3 @@ instance, if the files are modified under our feet.
 
 Old versions of rsync doesn't send any checksum. More recent versions
 do, but use md4 rather than md5.
-
-  
-
-
-
-
-First, an md5 checksum of the entire file (to catch
-errors, for instance if the files are being updated under our feet),
-
- 16 octets md5 checksum of file
-
-Next,  
-
-

src/rsync/rsync.h

@@ -46,13 +46,15 @@
 /* Size of block count, block size, tail */
 #define RSYNC_HEADER_SIZE 12
 
-/* Size of weak sum, md5 sume */
+/* Size of weak sum, md5 sum */
 #define RSYNC_ENTRY_SIZE 20
 
+#define RSYNC_TOKEN_SIZE 4
+
 /* Initial checksum calculations (by the receiver) */
 
 /* NOTE: Unlike zlib, we want to know the file size before we start.
- * This could be relxed, but requires some modifications to the
+ * This could be relaxed, but requires some modifications to the
  * protocol. */
 struct rsync_generate_state
 {
@@ -111,7 +113,7 @@ int rsync_generate_init(struct rsync_generate_state *state,
  *
  * -1 on failure (and it has to check INDEX and OFFSET for validity).
  * 0 if copying succeeds, but not all of the block was copied.
- * 1 if copying succeeds, and the final octet of the data swas copied.
+ * 1 if copying succeeds, and the final octet of the data was copied.
  *
  * On success, the function should set *DONE to the amount of data copied.
  */
@@ -134,16 +136,17 @@ struct rsync_receive_state
   rsync_lookup_read_t lookup;
   void *opaque;
   
-  struct md5_ctx full_sum; /* Sum of all input data */
+  struct md5_ctx full_sum; /* Sum of all the output data */
 
   /* Private state */
 
+  /* This is really an enum rsync_receive_mode */
   int state;
   
   UINT32 token; 
   UINT32 i;
 
-  UINT8 buf[MD5_DIGESTSIZE];
+  UINT8 buf[RSYNC_SUM_LENGTH];
 };
 
 int rsync_receive(struct rsync_receive_state *state);
@@ -204,8 +207,11 @@ struct rsync_send_state
   /* Length of literal to output. */
   UINT32 literal;
 
-  UINT8 token_buf[4];
-  UINT32 token_length;
+  UINT8 token_buf[RSYNC_TOKEN_SIZE];
+  UINT8 length_buf[RSYNC_TOKEN_SIZE];
+
+  /* Non-zero if the final EOF-token has been buffered for output. */
+  int final;
   
   unsigned sum_a;
   unsigned sum_b;