[librsync-devel] Re: state of the rsync nation? (revisited
6/2003 from 11/2000)
mbp at samba.org
Fri Jun 13 10:34:18 EST 2003
On 12 Jun 2003, Brad Hards <bhards at bigpond.net.au> wrote:
> Hash: SHA1
> On Wed, 11 Jun 2003 11:25 am, Martin Pool wrote:
> > That could be a pretty nice thing. We use little rsync shares on
> > workstations here for sharing files, and I know some people do the
> > same with FTP.
> > What aside from SLP would make this more useful?
> A standardised way of describing the share would be good. By this, I don't
> mean a software implementation, but a user / admin configuration. Think
> Standard Operating Procedures.
> The other thing that would be nice would be a search capability - "find me the
> shares with a copy of rsync-2.5.6.tar.bz2"
> 1. I'm thinking about something that, as a minimum, doesn't do plain text
> passwords. I admire clever attacks as much as the next guy, but the next guy
> doesn't want some kewl hax0r with a copy of tcpdump uploading warez either.
> Probably SASL is worth a look.
Yes, SASL looks like the way to go, at least for authentication.
Some things I read indicate that SASL is not a good choice for
encryption/integrity. So perhaps we should use SASL just for
authentication, and SSL for confidentiality/integrity. Does that make
> Why run this _only_ over TCP? Obviously you don't want to re-invent TCP/IP
> error handling, but the protocol shouldn't rely on such a system. File
> transfer can potentially run connectionless.
It sounds like you're talking about something like NFS (XDR-RPC) that
can run over UDP or TCP?
I wouldn't rely on TCP specifically, but I think it's OK to rely on a
byte stream channel, such as TCP or SSH.
I suppose if you're going to do UDP then you might want to try to do
multicast too, but that makes things like error handling a lot harder.
But I do think there should be a layer at which there are distinct
messages, and that what goes under that might be something other than
a byte stream in future.
More information about the rsync