[comp.org.usenix] SLIP or PPP instead of G proto

peter@ficc.uu.net (Peter da Silva) (12/08/89)

One thing that people seem to miss in the discussion of whether SLIP or PPP
is appropriate for uucp++ is that the current connect-time efficient batch
protocol can be maintained, with a uucp spool directory and so on, under IP.

You just queue up the requests, and when time comes to poll you dial-up,
go into IP, and transfer files in both directions as fast as you can. Then
you hang up and run uuxqt.

This wouldn't even need to allow interactive use of the link. Phil Karn's
KA9Q would do just fine, without even dealing with real sockets. But you
could also *add* sockets later and start interacting with that big old hub
when you got better software.

The problem is how you set up something like dial-up IP started under a
hypothetical modular UUCP. Any ideas? At least design your uucp++ so that
full-duplex protocols like IP can co-exist with it.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.

      "If you want PL/I, you know where to find it." -- Dennis

fair@Apple.COM (Erik E. Fair) (12/13/89)

Peter, what you describe is the same (functionally) as UUCP is now. If
you're not going to use it interactively, why bother to "connect" over
a dialup link with IP?

	Erik E. Fair	apple!fair	fair@apple.com

peter@ficc.uu.net (Peter da Silva) (12/14/89)

In article <37222@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes:
> Peter, what you describe is the same (functionally) as UUCP is now. If
> you're not going to use it interactively, why bother to "connect" over
> a dialup link with IP?

That's a good question. Luckily, I happen to have a good answer. It's, um,
right here. Hold on...

Because what I describe is the base fallback position for PPP (expensive
phone lines, no IPC, no sockets), but it's the best you can get with g-proto.
If this is generally available, it will enable you to hook in to local
PPP (say, over a dedicated 9600 baud line across the room). That is, by
basing a new uucp on dialup-IP you provide a path to full IP.

If you have a full-service system, you could use PPP links to connect
sites in a virtual uucp. And if you've got a socket implementation you
could (for example) piggyback telnet sessions or conventional FTP over
the UUCP session.

Here at Ferranti, we have several machines that are only available via UUCP.
Having a UUCP based on PPP would let us bring them closer into the main
network.

So, UUCP locks you into intermittent homogenous connections. IP lets you
work like UUCP, but also provides the option of expanding to continuous
heterogenous connections more in keeping with today's networks. It's a
superset.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

henry@utzoo.uucp (Henry Spencer) (12/15/89)

In article <37222@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes:
>Peter, what you describe is the same (functionally) as UUCP is now. If
>you're not going to use it interactively, why bother to "connect" over
>a dialup link with IP?

Apart from the potential for interoperability, which Peter has already
mentioned, there is the not-inconsequential issue of using a protocol
which is *documented* (in a complete, accurate, and redistributable way).
-- 
1755 EST, Dec 14, 1972:  human |     Henry Spencer at U of Toronto Zoology
exploration of space terminates| uunet!attcan!utzoo!henry henry@zoo.toronto.edu