superlifter design notes (OpenVMS perspective)

jw schultz jw at
Sun Jul 21 23:46:06 EST 2002

On Mon, Jul 22, 2002 at 04:31:51PM +1000, Martin Pool wrote:
> On 21 Jul 2002, jw schultz <jw at> wrote:
> > That is the better approach.  Use I/O routines so most
> > processing can be "while (get_input()) { process(); send_output()}"
> > Then the I/O routines can be defined accorinding to platform.
>   while 1:
>     examine fd
>     if input available:
>       read input packet
>       if a reply:	
>         dispatch to whoever was waiting for that reply
>       else if a request:
>         dispatch to whoever handles that request
>     if ready for output:
>       send next output packet from queue

I'm confusing subthreads here but the my psuedo snippit is
how a given component in the pipeline might work
and your little snippit is one way of connecting the

> You could do this with blocking IO, nonblocking, or even potentially
> threads, if you were on W32 (and drunk) and threads seemed like a
> really good idea.
> > If a platform has some special type of file it would be
> > responsible for converting to/from a multi-segment
> > bytestream.
> Yes.
> > It would be possible to build a server that didn't depend on
> > local filesystem semantics and so could support an attribute
> > superset.  But that is out of scope for now.
> One idea that both Samba and Subversion have is a virtual filesystem
> layer that mediates access to the local filesystem.  The default
> implementation maps straight down to regular IO, but you could plug in
> different implementations.  For example, you might want to store
> everything in one big database, so that the server can hold backup
> files with the clients semantics regardless of its native filesystem.

Get the protocol right and have clearly defined components
and we can do almost anything we want on the server.

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list