Added Cyg-Win
This commit is contained in:
parent
82cbc206eb
commit
413c315806
10586 changed files with 3806249 additions and 0 deletions
110
Agent-Windows/OGP64/usr/share/doc/rsync/csprotocol.txt
Normal file
110
Agent-Windows/OGP64/usr/share/doc/rsync/csprotocol.txt
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue