morgan@jessica.stanford.edu (RL "Bob" Morgan) (08/14/90)
Those of you who have followed the PC network software interface spec wars over the last couple of years know that there are three competing proposals in the market now: FTP Software's Packet Driver (which suffers from not having a 3- or 4-letter acronym), 3Com/Microsoft's Network Driver Interface Spec (NDIS), and Novell/Apple's Open Data-Link Interface (which may be ODI, though that may be tm of somebody else). This is a classic case of the unpleasant thing about standards being that there are too many to choose from. In my limited experience with trying to put together nets with brand-X PCs, brand-Y network cards, and brand-Z network software, I've run into products using all of these specs. You need to have support of a particular spec from all the products you want to stick into a particular PC for them all to work, of course, which turns out to be tricky at best. Who supports what is entirely political, it seems. In looking at 10Base-T cards recently, 3Com and HP both supply only NDIS drivers, since they're both Lan Manager vendors. Their ideas of what to put in the PROTOCOL.INI file seem to be at odds, though. Cabletron supplies a PD driver, with a curious extra bit of software to allow NDIS to run on top too. Of course, PD software for zillions of cards is available from Clarkson, etc. The Wollongong WINTCP software that we use supports both PD and NDIS, which is nice, but not ODI. ODI only shows up when you use AppleShare PC, which won't work with PD or NDIS. It's my understanding that the server part of Netware 386 also demands ODI. Curiously, Netware client software doesn't use Novell's ODI spec. Most people who are into this stuff seem to use PD with Netware clients. I've spent a few days now being amused that it takes years of experience and considerable clairvoyance to install a network board and some software and actually do something (and I'm only interested in making Telnet work). Consulting opportunities abound, clearly. So: 1) Are vendors of network boards producing ODI drivers? Does anyone know of any? 2) Are vendors of IP software for PCs producing ODI interface software for their packages? Does anyone know of any? 3) Has anyone produced AppleTalk software for PCs that uses one of the more mainstream specs (ie, not ODI)? I personally think it's quite stupid of Apple not to have done this already, but then, maybe they have a vested interest in this stuff failing . . . - RL "Bob" Morgan Networking Systems Stanford
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (08/14/90)
Quoth morgan@jessica.stanford.edu (RL "Bob" Morgan) (in <1990Aug13.234051.19998@portia.Stanford.EDU>): #2) Are vendors of IP software for PCs producing ODI interface #software for their packages? Does anyone know of any? We're not doing anything with ODI [I thought the acronym was "ODLI"?] for PC-NFS. I don't know of any customer or board vendor that has suggested that we should. We are adding NDIS support in the next release (the driver is already available from Clarkson), and are evaluating the feasibility of switching to NDIS completely. The main obstacles seem to be bloat (we've seen some unreasonably big and/or slow NDIS drivers from board vendors who have also written tiny drivers for the PC-NFS LLDK [Link Level Driver Kit]) and ease-of-use: I don't want to require users to go in and edit PROTOCOL.INI files, but I haven't found a good way around this yet in the general case. Why not adopt PD instead? Because in principle I think that NDIS does demultiplexing "right" and ODLI and PD do it "wrong". I prefer a procedural model, where a frame (or at least some part of the frame) is offered to each protocol stack which can accept or reject it, to one where the driver does the filtering based upon some template. If the template mechanism is rich enough to do everything I could imagine wanting to, it is bound to be slower and larger than any single protocol-specific recognition procedure. -- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) -- ** Back in the USA after a month in England. Most memorable scene: visiting ** ** the "Duke Humfrey" library (part of the Bodleian in Oxford): wonderful ** ** 15th century ceiling, incanabulae and desks, the latter with PCs on... **
ljm@OBELIX.TWG.COM (08/15/90)
>Are vendors of IP software for PCs producing ODI interface >software for their packages? Does anyone know of any? We have an ODI driver in house for WIN/TCP for DOS which will be included in our next release. I note with mock amazement, that we now have to support six 'standard' NIC interfaces: our own, FTP Software's PD, Microsoft's NDIS, Novell's ODI, DEC's DLL, and IBM's ASI. Ah, yes, standards are wonderful -- there are so many to choose from. enjoy, leo j mclaughlin iii The Wollongong Group ljm@twg.com
nelson@sun.soe.clarkson.edu (Russ Nelson) (08/15/90)
In article <2397@east.East.Sun.COM> geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
Why not adopt PD instead? Because in principle I think that NDIS does
demultiplexing "right" and ODLI and PD do it "wrong".
If *that*'s your only objection to the PD, then we can bash jbvb@ftp.com over
the head until he changes the spec to allow multiple drivers to be upcalled
with the same packet. Then your application can just ask for all packets.
I prefer a procedural model, where a frame (or at least some part
of the frame) is offered to each protocol stack which can accept or
reject it, to one where the driver does the filtering based upon
some template. If the template mechanism is rich enough to do
everything I could imagine wanting to, it is bound to be slower and
larger than any single protocol-specific recognition procedure.
But the procedural model bogs down in the details. How do you write a
procedural model that works equally well on I/O and memory-mapped cards?
The PD gets around this by letting you examine at most 8 bytes of the
packet, and only 4 of these make sense for Ethernet.
Perhaps the reason you've seen NDIS drivers that are big and slow is
because the NDIS spec is big (and requires slowness)? Perhaps because
NDIS comes from that firm whose products are big and slow (bash,
bash)? It's no coincidence that the packet drivers are shipped to
assemble with tasm, and link with tlink.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667
We won the cold war. The Russians spent trillions defending their stuff,
then they found that they didn't have any stuff. Will we avoid the same trap?jbvb@FTP.COM ("James B. Van Bokkelen") (08/16/90)
I appreciated the existence of ASI; Up till now there has been a single standard way to talk to 802.5 boards, and it was available from all vendors. IBM only broke my code once, by not obeying their own spec in the LAN Support Program. Now, however, NDIS v1 for 802.5 has reared its head (sans any un-bind support), and so a Class 3 packet driver is under test and will see the light of day next month. I looked at ODI early on, and found that it had some advantages over NDIS, and some disadvantages: As Geoff says, the demultiplexing method is "you ask for the packet types you want", but the last draft I saw specified a fixed 6-byte field for the demultiplexing information. This is insufficient for RFC 1042, and I told the people at Novell, but I assume they chose to hack around it instead of allocate more space. ODI provides a good deal of buffer management functionality, which is good if you can use it effectively. It is also likely to be handicapped in somewhat the same way as NDIS was initially, in that the buffer management layer is only available from Novell or Netware OEMs as part of Netware (as the NDIS Protocol Manager was initially bundled with LAN Manager). We may do an ODI interface if there is demand, but so far we haven't seen any ODI hardware drivers. Maybe I should hassle some of the board vendors, because it sounds like Leo has seen at least one. We're far away from most of them, and sometimes they forget... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
jbvb@FTP.COM ("James B. Van Bokkelen") (08/16/90)
From: Russ Nelson <nelson@sun.soe.clarkson.edu>
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS) writes:
Why not adopt PD instead? Because in principle I think that NDIS does
demultiplexing "right" and ODLI and PD do it "wrong".
If *that*'s your only objection to the PD, then we can bash jbvb@ftp.com
over the head until he changes the spec to allow multiple drivers to be
upcalled with the same packet. Then your application can just ask for all
packets.
The problem is of course the slow, DMA-based boards. The Packet Driver
spec doesn't prevent a given driver from allowing simultaneous "match all"
and "specific packet" handles. Our own NDIS-to-Packet-Driver doesn't (and
won't) support multiple driver upcalls primarily because the NDIS spec
doesn't guarantee that an NDIS driver can deliver the same packet to more
than one stack, and we needed to minimize size.
Version 1.10 of the packet driver spec is in the works. A revision of
the as_send_pkt() function has been implemented and tested by Drew
Perkins. Since Drew proposed the original version, and I don't know
of anyone who implemented it, I am moved to include this in the new
spec. However, I have seen requests for gather-mode on output. I am
soliciting people to propose (write up and hopefully test) extensions
to Drew's mechanism.
As far as "look at the packet before it is copied to my buffer" goes,
there are certainly a lot of free registers on the first 'receiver()'
upcall. The 'get_parameters()' function allows the stack to
determine the PDS revision the driver conforms to. Suppose that with
v1.10 of the spec, if the DX register is non-zero on the 'AX == 0'
upcall, it is the length of a 'look-ahead' buffer pointed to by
register pair ES:DI. If the stack doesn't want the packet after all,
it can just return an empty buffer pointer. One could also guarantee
a minimum length of 60 bytes in Class 1, possibly larger in Class 3.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901