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