Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!cuae2!cwd
From: cwd@cuae2.UUCP
Newsgroups: comp.unix.questions,comp.sys.att
Subject: Re: NPACK protocol
Message-ID: <9480@cuae2.ATT.COM>
Date: Sun, 12-Apr-87 11:28:03 EST
Article-I.D.: cuae2.9480
Posted: Sun Apr 12 11:28:03 1987
Date-Received: Wed, 15-Apr-87 00:39:31 EST
References: <242@pyuxe.UUCP>
Sender: usenet@cuae2.ATT.COM
Reply-To: cwd@cuae2.UUCP (-Chris Donahue)
Organization: AT&T - /app/eng, Lisle, IL
Lines: 26
Keywords: STREAMS, NPACK
Xref: utgpu comp.unix.questions:1702 comp.sys.att:304

NPACK was developed so RFS could be developed. STARLAN development and RFS
development were done in parallel. The RFS folks needed something to test
their product with, so NPACK was developed. Yes, RFS does run over NPACK.
My organization received NPACK as part of the SVR3 alpha site program and
we still use it. It works but it is gross to build addresses for it.
For example, you have to find your Ethernet address to build RFS addresses
for the name servers. You must use "crash" to obtain it. Then you
prepend the address with \x00000007 for general purpose listening service
and with \x00000008 for terminal login service. In both cases, you append
the address with 0000. For uucp service, you must translate this monster
address into octets. You take each hex byte and build an octet. If you
would like to insulate the world from this, you must build your own symbolic
address translator. 

The real catch is that NPACK is not an official product. You pay for source
so you can support it yourself. We have never found any drastic bugs in it,
but you are on your own. If you have to have Ethernet now, it's your only
choice. If you can wait a while longer, STREAMS TCP/IP will be available.
This gives you RFS and UUCP as well as all of the nice things TCP/IP
includes.

Hope this helps.

Chris Donahue
AT&T Data Systems Div.
Customer Systems Engineering