lee@ROCHESTER.ARPA (08/28/84)
From: Lee Moore <lee@ROCHESTER.ARPA> Item 1: Pup Anybody who has tried using the Pup support under 4.2 knows that it has never been tested against Xerox hardware. A guy here hacked this once for 4.1c but under 4.2 we are running the Stanford Pup code. Did anybody bother to fix the Pup protocols for 4.2? Item 2: non-IP Has anybody implemented any non-internet protocols under 4.2? Staring at the code, I see some Internet dependencies lurking around. Has anybody straightened them out? I have some ideas on how things should be but I would be interested in other opinions. Many thanks, lee
creon@ames-nas-gw.arpa (08/28/84)
From: Creon Levit <creon@ames-nas-gw.arpa> I have installed another protocol under 4.2. It is a subset of SCP, which is Cray Research's "Station Call Protocol" that a Cray running COS uses to communicate with front ends. It is very primitive and depends on the particular characteristics of the [NSC HYPERchannel] hardware that it runs on. The protocol does double duty as a "raw" path to the HYPERchannel, somewhat like the raw 3Mbit ethernet stuff that is included. However, one still uses socket(2), bind(2), sendto(2), etc. to use the prototcol. Also, I beleive that Some people at Lawrence Livermore are putting Their protocol (LINCS) under the socket structure. (I tried to do the same thing with LINCS once, but didn't know enough at the time). There is a substantial amount of DECNET code under sockets on the latest berkeleytapes, though it still looks incomplete. I beleive it is being done by DEC for Ultrix-32 (tm), though I'm not sure. There is also the "network disk" protocol of Sun microsystems, and some SNA software rumored to be available, thoughI don't know from whom. I think you can expect more and more protocols to run under 4.2bsd. It looks like it was designed to be a "gateway" architecture, trading in performance for more flexibility. For example, one process can have several sockets, each using a different protocol, and move data between them. As for internet dependencies, my experience was that it was my dependencies on the internet code that screwed me, rather than the system's dependencies on the internet code. ----------
CFrankston@MIT-MULTICS.ARPA (09/02/84)
From: Charles Frankston <CFrankston@MIT-MULTICS.ARPA> MIT's Chaos protocol has been brought up under 4.2. It is NOT integrated into the Berkeley socket mechanism. It can be used with either Interlan or DEUNA Ethernet drivers, MIT Chaos net boards (rather rare), and probably DEQNA drivers by now. The Interlan and DEUNA drivers require you to configure your machine at least with a Internet address since it uses the Berkeley IP driver for those devices. This is so machines running both IP and Chaos need only one Ethernet interface. Available services are comparable to TCP/IP -- Telnet (based on Arpanet new telnet protocol), Supdup, File Transfer, remote finger etc. There is probably no real reason why a site that didn't already have an MIT type Chaos net in place (there are perhaps 10 serious such sites besides MIT) would want to use this in preference to TCP/IP.
jdd@allegra.UUCP (John DeTreville) (09/04/84)
Although the Chaos software for 4.2 comes configured for a small number of
controller types, a simple examination of the ocde will show you the secret
of making it work with any controller. We use it, for example, with old
3Com controllers on some of our machines, and it works just fine.
Cheers,
John ("Tired of UNIX") DeTreville
Bell Labs, Murray Hill