Return to csprotocol.txt CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / rsync

Annotation of embedaddon/rsync/csprotocol.txt, revision 1.1.1.1

1.1       misho       1: This is kind of informal and may be wrong, but it helped me.  It's
                      2: basically a summary of clientserver.c and authenticate.c.
                      3: 
                      4:  -- Martin Pool <mbp@samba.org>
                      5: 
                      6: 
                      7: This is the protocol used for rsync --daemon; i.e. connections to port
                      8: 873 rather than invocations over a remote shell.
                      9: 
                     10: When the server accepts a connection, it prints a greeting
                     11: 
                     12:   @RSYNCD: <version>.<subprotocol>
                     13: 
                     14: where <version> is the numeric version (see PROTOCOL_VERSION in rsync.h)
                     15: '.' is a literal period, and <subprotocol> is the numeric subprotocol
                     16: version (see SUBPROTOCOL_VERSION -- it will be 0 for final releases).
                     17: Protocols prior to 30 only output <version> alone.  The daemon expects
                     18: to see a similar greeting back from the client.  For protocols prior to
                     19: 30, an absent ".<subprotocol>" value is assumed to be 0.  For protocol
                     20: 30, an absent value is a fatal error.  The daemon then follows this line
                     21: with a free-format text message-of-the-day (if any is defined).
                     22: 
                     23: The server is now in the connected state.  The client can either send
                     24: the command
                     25: 
                     26:   #list
                     27: 
                     28: to get a listing of modules, or the name of a module.  After this, the
                     29: connection is now bound to a particular module.  Access per host for
                     30: this module is now checked, as is per-module connection limits.
                     31: 
                     32: If authentication is required to use this module, the server will say
                     33: 
                     34:   @RSYNCD: AUTHREQD <challenge>
                     35: 
                     36: where <challenge> is a random string of base64 characters.  The client
                     37: must respond with
                     38: 
                     39:   <user> <response>
                     40: 
                     41: where <user> is the username they claim to be, and <response> is the
                     42: base64 form of the MD4 hash of challenge+password.
                     43: 
                     44: At this point the server applies all remaining constraints before
                     45: handing control to the client, including switching uid/gid, setting up
                     46: include and exclude lists, moving to the root of the module, and doing
                     47: chroot.
                     48: 
                     49: If the login is acceptable, then the server will respond with
                     50: 
                     51:   @RSYNCD: OK
                     52: 
                     53: The client now writes some rsync options, as if it were remotely
                     54: executing the command.  The server parses these arguments as if it had
                     55: just been invoked with them, but they're added to the existing state.
                     56: So if the client specifies a list of files to be included or excluded,
                     57: they'll defer to existing limits specified in the server
                     58: configuration.
                     59: 
                     60: At this point the client and server both switch to using a
                     61: multiplexing layer across the socket.  The main point of this is to
                     62: allow the server to asynchronously pass errors back, while still
                     63: allowing streamed and pipelined data.
                     64: 
                     65: Unfortunately, the multiplex protocol is not used at every stage.  We
                     66: start up in plain socket mode and then change over by calling
                     67: io_start_buffering.  Of course both the client and the server have to
                     68: do this at the same point.
                     69: 
                     70: The server then talks to the client as normal across the socket,
                     71: passing checksums, file lists and so on.  For documentation of that,
                     72: stay tuned (or write it yourself!).
                     73: 
                     74: 
                     75: 
                     76: ------------
                     77: Protocol version changes
                     78: 
                     79: 30     (2007-10-04, 3.0.0pre1)
                     80: 
                     81:        The use of a ".<subprotocol>" number was added to
                     82:        @RSYNCD: <version>.<subprotocol>
                     83: 
                     84: 25     (2001-08-20, 2.4.7pre2) 
                     85: 
                     86:        Send an explicit "@RSYNC EXIT" command at the end of the
                     87:        module listing.  We never intentionally end the transmission
                     88:        by just closing the socket anymore.