Future RSYNC enhancement/improvement suggestions

[David Bolen]

Martin Pool [mbp at sourcefrog.net] writes:

> I guess alternatively you could set the rsync timeout high, the
> line-drop timeout low, and make it dial on demand.  That would let the
> line drop when rsync was really thinking hard, and it would come back
> up as necessary.  Losing the ppp channel does not by itself interrupt
> any tcp sessions running across it, provided that you can recover the
> same ip address next time you connect.

That assumes an environment where dial-on-demand is feasible.
Unfortunately, our particular setup is a direct PC to PC dial, and
there's no IP involved (it's Windows<->Windows with NETBIOS/NETBEUI)
so disconnecting would shut down the remote rsync.

But it's an interesting thought for cases where it could get used.  In
general I'd expect it to be fairly fragile though unless you had
complete control of the dial infrastructure or could otherwise ensure,
as you note, identical IP address assignment.

I don't suppose anyone knows any legacy reason why all the checksums
are computed and stored in memory before transmission do they?  I
don't think at the time I could find any real requirement in the code
that it be done that way - the sequence was pretty much
generate/send/free.

-- David

/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/