rsync - May 2007 - Transport Performance / Protocol Overhead (remote shell vs daemon)

Does anyone know how these rsync transport methods compare?:

1) Rsync to remote host via an ssh tunnel to an Rsync daemon
vs.
2) Rsync to remote host via ssh remote shell

- Is there a performance difference in throughput or latency?
- Which one has higher protocol overhead?
- Does it matter if we are sending files or receiving them?
- Any memory usage differences?
- Security implications?  Is one more secure than another?

Thanks,

Wayne

On 5/24/07, Wayne Sherman <wsherman@apexelectriclv.com>
wrote:
> Does anyone know how these rsync transport methods compare?:
>
> 1) Rsync to remote host via an ssh tunnel to an Rsync daemon
> vs.
> 2) Rsync to remote host via ssh remote shell
I'll try to answer this.  Wayne Davison (this is going to get
confusing), please correct me as necessary.

By #1, I assume you mean a single-use rsync daemon invoked over ssh, like this:

rsync -e ssh rsync://host/module/src/ dest/

If you mean a background daemon contacted over a port forwarded by
ssh, tell me because many of the answers would be different.
> - Is there a performance difference in throughput or latency?
> - Which one has higher protocol overhead?
#1 has slightly greater overhead to open a session, but once the run
is in progress, both methods have essentially identical performance.
> - Does it matter if we are sending files or receiving them?
No.
> - Any memory usage differences?
Not likely to be significant.  The only one I can think of is that, in
#1, the daemon stores its configuration settings in memory.
> - Security implications?  Is one more secure than another?
#2 requires the client to have full access to the shell account on the
remote host.  #1 can be configured so that all the client can do with
the shell account is rsync files to or from directories you specify,
and you can limit the rsync options allowed.  In both methods, ssh
encryption prevents third parties from reading or modifying the data
in transit.

Matt

> If you mean a background daemon contacted over a
> port forwarded by ssh, tell me because many of the
> answers would be different.
Yes, that.  I guess I should have been more specific.
:-)

Thanks,

Wayne