[librsync-devel] Re: state of the rsync nation? (revisited 6/2003 from 11/2000)

[Martin Pool]

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"

OK, interesting.

> 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
any sense?

> 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.

-- 
Martin