Commit 588335c2 authored by Niels Möller's avatar Niels Möller
Browse files

*** 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
parent 91a53ea6
......@@ -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
*
......
......@@ -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. */
......
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,
......@@ -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;
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment