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