Andrew_Tuline@mindlink.UUCP (Andrew Tuline) (01/28/91)
Forgive a fairly basic question. What is a packet driver, and who supplies them? For instance, I have some WD8003E adapters, and am interested in having them talk TCP/IP. Do they have to be on the same cable as the TCP/IP system or can these drivers actually get routed through a server? Do the drivers some with Netware 2.1X and I just haven't found them, or do they come from the board manufacturer or what? I sure would appreciate an explanation of their purpose and capabilities. BTW, we use Performance Technologies Netsave with an Exabyte tape drive. It's much faster than Emerald which I also reviewed when they were the first companies with Exabyte support. It's too bad Performance doesn't support MAC backups. I'd be interested in a package that backs up 2.1X, 3.1, and MAC . The only ones I've seen that do all 3, are VAP's or NLM's, (which I don't want).
nelson@sun.soe.clarkson.edu (Russ Nelson) (01/30/91)
Here's Joe Doupnik's introduction to packet drivers, and the need for same:
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)
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) FAX 315-268-7600
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.alan@curly.Viewlogic.COM (Alan Medsker) (01/30/91)
In article <4601@mindlink.UUCP>, Andrew_Tuline@mindlink.UUCP (Andrew Tuline) writes: |> backups. I'd be interested in a package that backs up 2.1X, 3.1, and MAC . |> The only ones I've seen that do all 3, are VAP's or NLM's, (which I don't |> want). Palindrome's TNA may do what you want, with no VAPs or NLMs. Alan -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alan Medsker Viewlogic Systems, Inc. Voice: (508) 480-0881 293 Boston Post Road West Fax: (508) 480-0882 Marlboro, MA 01752 Internet: amedsker@Viewlogic.COM cc:Mail: Alan Medsker at Viewlogic CI$: 76376,662 BIX: amedsker 2 Meters: WB0SQR =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= My opinions, of course. And don't hold me to them. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=