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

[jw schultz]

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