[librsync-devel] Re: state of the rsync nation? (revisited
6/2003 from 11/2000)
jw at pegasys.ws
Fri Jun 13 11:06:04 EST 2003
On Fri, Jun 13, 2003 at 10:34:18AM +1000, Martin Pool wrote:
> On 12 Jun 2003, Brad Hards <bhards at bigpond.net.au> wrote:
> > 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.
Leave the communications protocol to the communications
layer. You don't save anything by coding reordering and
retransmission at the packet level; that is infrastructure.
Connectionless is fine. Lightweight sessions is better. If
you lose a connection a restart is possible. It is
preferable to not have to authenticate and negotiate
protocol versions and encryption with every message.
Think in terms of transactions. Each transaction is atomic.
If a transaction doesn't complete you have the means to
roll-back and retry. If a connection breaks between
transactions, or leaving a transaction incomplete, you start
a new connection and pick up where you left off.
J.W. Schultz Pegasystems Technologies
email address: jw at pegasys.ws
Remember Cernan and Schmitt
More information about the rsync