to iie:
现在源码已经是我们公司的了，所以就不能公开了。
关于PACKET DRIVER 看看下面的摘录的一段
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
Crynwr Software, Russ Nelson, nelson@crynwr.com.
不过这年头写DOS程序的人好象是不多了，人都是急功近利的...
