summaryrefslogtreecommitdiffstats
path: root/csprotocol.txt
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-17 16:14:31 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-17 16:14:31 +0000
commit2d5707c7479eacb3b1ad98e01b53f56a88f8fb78 (patch)
treed9c334e83692851c02e3e1b8e65570c97bc82481 /csprotocol.txt
parentInitial commit. (diff)
downloadrsync-2d5707c7479eacb3b1ad98e01b53f56a88f8fb78.tar.xz
rsync-2d5707c7479eacb3b1ad98e01b53f56a88f8fb78.zip
Adding upstream version 3.2.7.upstream/3.2.7
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'csprotocol.txt')
-rw-r--r--csprotocol.txt110
1 files changed, 110 insertions, 0 deletions
diff --git a/csprotocol.txt b/csprotocol.txt
new file mode 100644
index 0000000..7ba09ab
--- /dev/null
+++ b/csprotocol.txt
@@ -0,0 +1,110 @@
+This is kind of informal and may be wrong, but it helped me. It's
+basically a summary of clientserver.c and authenticate.c.
+
+ -- Martin Pool <mbp@samba.org>
+
+
+This is the protocol used for rsync --daemon; i.e. connections to port
+873 rather than invocations over a remote shell.
+
+When the server accepts a connection, it prints a newline-terminated
+greeting line:
+
+ @RSYNCD: <version>.<subprotocol> <digest1> <digestN>
+
+The <version> is the numeric version (see PROTOCOL_VERSION in rsync.h)
+The <subprotocol> is the numeric subprotocol version (which is 0 for a
+final protocol version, as the SUBPROTOCOL_VERSION define discusses).
+The <digestN> names are the authentication digest algorithms that the
+daemon supports, listed in order of preference.
+
+An rsync prior to 3.2.7 omits the digest names. An rsync prior to 3.0.0
+also omits the period and the <subprotocol> value. Since a final
+protocol has a subprotocol value of 0, a missing subprotocol value is
+assumed to be 0 for any protocol prior to 30. It is considered a fatal
+error for protocol 30 and above to omit it. It is considered a fatal
+error for protocol 32 and above to omit the digest name list (currently
+31 is the newest protocol).
+
+The daemon expects to see a similar greeting line back from the client.
+Once received, the daemon follows the opening line with a free-format
+text message-of-the-day (if any is defined).
+
+The server is now in the connected state. The client can either send
+the command:
+
+ #list
+
+(to get a listing of modules) or the name of a module. After this, the
+connection is now bound to a particular module. Access per host for
+this module is now checked, as is per-module connection limits.
+
+If authentication is required to use this module, the server will say:
+
+ @RSYNCD: AUTHREQD <challenge>
+
+where <challenge> is a random string of base64 characters. The client
+must respond with:
+
+ <user> <response>
+
+The <user> is the username they claim to be. The <response> is the
+base64 form of the digest hash of the challenge+password string. The
+chosen digest method is the most preferred client method that is also in
+the server's list. If no digest list was explicitly provided, the side
+expecting a list assumes the other side provided either the single name
+"md5" (for a negotiated protocol 30 or 31), or the single name "md4"
+(for an older protocol).
+
+At this point the server applies all remaining constraints before
+handing control to the client, including switching uid/gid, setting up
+include and exclude lists, moving to the root of the module, and doing
+chroot.
+
+If the login is acceptable, then the server will respond with
+
+ @RSYNCD: OK
+
+The client now writes some rsync options, as if it were remotely
+executing the command. The server parses these arguments as if it had
+just been invoked with them, but they're added to the existing state.
+So if the client specifies a list of files to be included or excluded,
+they'll defer to existing limits specified in the server
+configuration.
+
+At this point the client and server both switch to using a
+multiplexing layer across the socket. The main point of this is to
+allow the server to asynchronously pass errors back, while still
+allowing streamed and pipelined data.
+
+Unfortunately, the multiplex protocol is not used at every stage. We
+start up in plain socket mode and then change over by calling
+io_start_buffering. Of course both the client and the server have to
+do this at the same point.
+
+The server then talks to the client as normal across the socket,
+passing checksums, file lists and so on. For documentation of that,
+stay tuned (or write it yourself!).
+
+
+
+------------
+Protocol version changes
+
+31 (2013-09-28, 3.1.0)
+
+ Initial release of protocol 31 had no changes. Rsync 3.2.7
+ introduced the suffixed list of digest names on the greeting
+ line. The presence of the list is allowed even if the greeting
+ indicates an older protocol version number.
+
+30 (2007-10-04, 3.0.0pre1)
+
+ The use of a ".<subprotocol>" number was added to
+ @RSYNCD: <version>.<subprotocol>
+
+25 (2001-08-20, 2.4.7pre2)
+
+ Send an explicit "@RSYNC EXIT" command at the end of the
+ module listing. We never intentionally end the transmission
+ by just closing the socket anymore.