Bug 5220 - Syntax to access a daemon over a socket supplied on a fd
Syntax to access a daemon over a socket supplied on a fd
Status: NEW
Product: rsync
Classification: Unclassified
Component: core
3.0.0
All Linux
: P3 enhancement
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-21 22:31 UTC by Davy Durham
Modified: 2009-01-12 23:18 UTC (History)
0 users

See Also:


Attachments
This patch implements the described feature (3.70 KB, patch)
2008-01-21 22:35 UTC, Davy Durham
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Davy Durham 2008-01-21 22:31:55 UTC
I've created a simple patch that allows the user to specify '&<integer>' for the hostname which causes it to use that specified file-descriptor as an already connected socket so that a program can connect for rsync, pre-communicate and then exec rsync (the normal stdio model).

The existing --rsh feature can perhaps just barely be used to do this if you bend over backwards, but this simplifies it.  But this allows the connection to be made  BEFORE even executing rsync rather than vice-versa.

I've also updated the man page.  I didn't know what else might need to be updated.  I'll be glad to enhance it further if necessary
Comment 1 Davy Durham 2008-01-21 22:35:44 UTC
Created attachment 3116 [details]
This patch implements the described feature

This patch has be preliminarily tested.  I will update if any issues are found while using in production.
Comment 2 Matt McCutchen 2008-01-23 00:55:41 UTC
You can make rsync effectively use an existing fd by passing an $RSYNC_CONNECT_PROG that refers to a program that shuttles data between its stdin/stdout and the desired fd.  I'm not sure that it is worth adding the & syntax to the official rsync.
Comment 3 Davy Durham 2008-01-23 10:59:09 UTC
(In reply to comment #2)
> You can make rsync effectively use an existing fd by passing an
> $RSYNC_CONNECT_PROG that refers to a program that shuttles data between its
> stdin/stdout and the desired fd.  I'm not sure that it is worth adding the &
> syntax to the official rsync.
> 

I'm aware of that, but you have to have yet another process and have some application to do that for you rather than follow the usual stdio pattern (set up fd, fork/exec).  This patch makes things more resource efficient.
Comment 4 Matt McCutchen 2008-06-02 15:56:00 UTC
I'm sorry for the noise as I try to get the summary right.

I've changed my mind about this enhancement: I'm now in favor of it because the implementation is so simple and it would provide a slightly easier and better-performing way to embed rsync in other programs that already have a network connection, such as my continusync (if I ever finish it).
Comment 5 Davy Durham 2008-06-03 22:19:10 UTC
(In reply to comment #4)
> it would provide a slightly easier and
> better-performing way to embed rsync in other programs that already have a
> network connection, such as my continusync (if I ever finish it).
> 

That's exactly the situation I had too. I had an existing network connection and wanted to let rsync have the rest of the traffic.  So I exec() rsync when I'm done talking to the other side (and he exec's it too).

Thanx
Comment 6 Matt McCutchen 2009-01-12 23:18:03 UTC
I noticed that this was proposed a long time ago:

http://lists.samba.org/archive/rsync/2003-March/005418.html

It looks like JW Schultz was proposing treating a client with a supplied connection as a special kind of server with am_server set to a distinctive value.  I don't think that approach will work now that the client/server distinction means many things besides whether to make a connection or use a provided one, so the current approach of just hooking the code that makes the connection is correct.