Packet Drivers, made simple 9 Jan 1990 by Joe R. Doupnik, Utah State University jrd@usu.Bitnet, jrd@cc.usu.edu 129.123.1.1 for Novell Technology Transfer Partnership The problem: Ethernet is a common, or the most common, large organization method of networking systems. To date, the many programs (applications) designed to talk across Ethernet all have built-in drivers for particular Ethernet boards. That means that each application owns the Ethernet board and other applications cannot use it simultaneously. Goodbye Novell file server(s) if TCP/IP is needed. That also has meant that different applications have not used a common pool of Ethernet boards and the user may have to install two of them, if that is possible on many PCs. Expensive and a real pain for system maintainers. Changing applications means reconfiguring the PC and then rebooting. The solution: Suppose some small piece of software owned the Ethernet board and provided a standard interface to all software packages. That would give standardization for the applications, and require only one board per PC. Further suppose this small item, named a Packet Driver, allowed applications to register themselves by saying to the P.D. - Pac baby: I want packets of the following kind(s) and when you see one like that call me at this address, immediately. (801) 555-1212. Sincerly, Big App Or even the reverse if the application is packing up shop and quiting. This second part allows multiple applications to come and go while the tiny Packet Driver remains in memory; it uses just a few Kbytes. And it allows several applications to register for different kinds of packets. Each application remains ignorant of traffic not destined for itself. Applications have to be built to use the Packet Driver interface rather than wanting an Ethernet board to themselves. They are now being written that way. Packet Drivers, made simple 2-3 Ethernet packet construction a packet, 64 to ~1000 bytes --------------------------------------------------------------- | preamble.. | from address | to address | TYPE | ...data.... | --------------------------------------------------------------- 6 bytes 6 bytes 2 bytes many bytes Regular Ethernet uses the TYPE field to hold a number which is the kind of protocol. Novell's TYPE is 8137. IEEE 802.3 Ethernet (much less popular) uses that field to count the number of bytes that follow, even though the Ethernet board itself provides that information. Thus, software must look in the data field to locate any protocol kind, and that will cost time and impose a load on machines. The TO address refers to an Ethernet hardware address, normally that set into the board by the manufacturer and hence unique in the world. But, a big headache is that address can be one to be received by several places or by all places (Multicast or Broadcast). Broadcast traffic hits every single board in the place. TCP and NFS and Unix systems love to broadcast, a lot. Packet Driver concept, from FTP Software Inc. -------------------- /======= coax ========> | Ethernet board |- T -------------------- \======= coax ========> | ----------------------------------------------------------------- Packet Driver == Owner of the Board Board interrupts Packet Driver, saying "Got another pkt for you". Get TYPE from board's packet buffer. Scan list of requestors to find match of TYPE and requestor's Type. If a match pass packet to requestor, clears board for next packet. If no match discard packet, clears board for next packet. ------------------------------------------------------------------ | | | ... | NetWare TCP/IP NFS other requestors Advantages: 1) Run multiple applications across the same board, simultaneously if req'd. Each registers and can deregister itself with the Packet Driver. 2) One board fits all, no buying different boards for different applications. Current boards: WD8003E, 3C501, 3C503, 3C523, NI5010, NI5210, DLINK, (NE-1000 running at USU), and more directly from vendors. Recommend the WD8003E, then the 3C503. The NE-1000 is similar to both. 3) Much faster filtering of "junk" packets, particularly and especially Broadcast and Multicast packets found on heavily used networks. 4) Consequence of 3) the PC uses far fewer cpu cycles servicing the network. 5) No more reconfiguring and rebooting to change applications. 6) Connect to a Novell File Server (or servers) and still run TCP/IP or PC-NFS or ... with the Novell systems remaining active and available for file serving and printing. 7) Thus the Packet Driver acts as a fast smart secretary, bothering clients only when packets arrive specifically for them. If an application has slow or weak code for handling packets then the P.D. is a boon. 9) Packet Driver size is very small and the P.D. + Novell Shell (IPX + NETx) is very nearly the same size as without a Packet Driver. 10) TYPE 8137 is REQUIRED by NetWare/VMS, no way around it. Packet Drivers, made simple 3-3 Other comments and opinions: 11) Alas, my experience is that ordinary Novell 2.1x File Servers are unable to cohabit a heavily used campus backbone for some kinds of boards. But converting the server to use Regular Ethernet packets with TYPE 8137 allows them to very rapidly discard unwanted pkts and live happily for weeks on end attached to a main backbone. Whew! 12) BYU and Novell have made life easy for us by providing the ECONFIG.EXE utility to convert file servers to TYPE 8137 and even to change shells to the same system. It's reversable too. Apply to NET$OS.EX1, and to IPX.COM (but only if not using Packet Drivers, else build IPX for PD). 13) FTP Software Inc has made life easy for us by providing the Packet Driver specification and making it public. 14) Ethernet board vendors are rapidly supplying Packet Drivers for their products. Hot stuff this year. From the user's side all P.D.'s are supposed to look alike; things are improving in this regard. 15) New Packet Drivers are being developed by individuals and are available at no cost across the networks. The central distribution point is Clarkson University, Russ Nelson, nelson@clutx.clarkson.edu. 16) Code and prebuilt drivers are available via anonymous ftp from Clarkson at sun.soe.clarkson.edu, 128.153.12.3, directories pub\packet-drivers and/or pub\ka9q, files drivers.arc (prebuilt), and/or driverss.arc (sources) pcnfs.arc.Z (PC-NFS Packet Driver support) directory pub\novell (material from BYU) file novell.exe or directly from BYU as anonymous ftp to dcsprod.byu.edu, 128.187.7.3 BYU's file NOVELL.EXE when run unpacks to - ECONFIG EXE 24269 4-15-88 2:25p PDLAN LAN 389 4-28-89 11:48a DPDLAN OBJ 2266 4-27-89 6:01p APDLAN OBJ 2266 4-27-89 6:00p READ ME 10008 4-29-89 2:59p PDSHELL LAN 144 4-28-89 11:40a BPDLAN OBJ 2266 4-27-89 6:01p PDSHELL OBJ 1632 4-27-89 5:53p CPDLAN OBJ 2266 4-27-89 6:01p where PDSHELL.OBJ files for 2.1 shell generation PDSHELL.LAN " and go into LAN_DRV_.00n APDLAN, BPDLAN, CPDLAN, DPDLAN, PDLAN.OBJ are Novell 2.1 LAN driver for bridges ECONFIG.EXE Novell's configuration utility for shells and drivers. (Type ECONFIG ? for help). READ.ME BYU's installation instructions (easy)