KGJHH@ASUACAD.BITNET (Jim Howard) (12/06/88)
Has anyone had a chance to compare the two specs for network drivers from FTP and Microsoft. Do they compare? Do they interfere? They seem to be generally trying to solve the same problem of multiple applications trying to access the same hardware. Is one better than the other. Have any vendors (hardware or software) committed to either? Jim Howard Manager, Technical Services Computing Services Customer Support Arizona State University Tempe, Arizona 85287 602-965-5677 Bitnet: KGJHH@ASUACAD
jbvb@VAX.FTP.COM (James Van Bokkelen) (12/10/88)
I have compared them. Allow for my bias, but here are what I see as the most important differences, in order: 1. Under DOS, the Microsoft NDIS-Mac spec requires that all binding (setting up to receive and send packets) take place while CONFIG.SYS is running. The Packet Driver spec allows access_type() at any time. 2. The NDIS-Mac spec has no mechanism to un-bind; once you're receiving packets you will continue to do so until a reboot (and if you just vanish, the world will crash). The Packet Driver spec allows release_type() at any time. 3. The NDIS-Mac spec makes no assumptions about packet acceptability criteria; It calls you, and you look at the packet, and return an indication of whether you want it. The Packet Driver assumes the use of a standard demultiplexing mechanism (e.g. Ethertype), and takes the match criteria as an argument to access_type(). This also requires a separate access_type()/release_type() for each packet type an application wishes to handle. 4. The NDIS-Mac spec requires an additional component (the Protocol Manager) to carry out the initial binding, over and above the MAC driver and the application. The Packet Driver spec only needs the MAC driver and the application to function. 5. The NDIS-Mac interface is based on far calls through arrays of addresses. The Packet Driver uses software interrupts for all but one function (the packet-received upcall). There are lots of other differences, but they are mostly implementation details, not really relevant. Neither spec attempts to hide the details of the MAC layer packet (or special MAC-level protocols like ARP) from the application. James VanBokkelen FTP Software Inc.
jbvb@VAX.FTP.COM (James Van Bokkelen) (12/13/88)
As an afterthought, if anyone wishes to do their own comparison: The text of the Microsoft NDIS-Mac Specification, v1.0.1 is available for anonymous FTP from vax.ftp.com, as "pub/ndis-mac.v101.txt". The text of the FTP Packet Driver Specification, v1.08 is on the same host, as "pub/packet-d.*". The .mss file is input for The FinalWord II (Borland Sprint, close to Scribe format). The .prn file is input for an HP Laserjet, with the TMS Proportional 2 font cartridge (use binary mode). The .ascii file is the text I am going to post to "pcip" in a moment... James VanBokkelen FTP Software Inc.
philipp@physicsa.mcgill.ca (Philip Prindeville Comp Ctr) (12/14/88)
James, you forgot one important difference: MAC also calls each registered client asking it "Do you want this packet?" So, the more clients you have the poorer the performance you get. Also depending on when a client registers, it may get better or worse performance. I like the packet driver spec way of demultiplexing much more (and there really is no excuse for not doing it that way, either). -Philip
romkey@asylum.sf.ca.us (John Romkey) (12/14/88)
>I like the packet driver spec way of demultiplexing >much more (and there really is no excuse for not doing it that >way, either). That's not true. I've never been completely happy with the way demultiplexing works in the packet driver. It doesn't work well in cases where you have IEEE packets with SNAP headers and Xerox blue book packets with type fields on the same ethernet. Generally, it doesn't work well in any environment where type information does not always start at the same place in a packet. I'd be much happier with a more flexible mechanism, but every mechanism I've tried is still too inflexible in one are or another. The MAC spec's approach is the single most general one I've seen, and it's flexible enough to suit me. The MAC approach opens you up to whole new methods of selecting packets - for instance, a network monitor could decide whether it wanted the packet before allocating buffer space to it - it could inspect every field in the packet that it cared about. Even using a packet driver with a general bit mask that each client would register wouldn't allow this flexibility. It's real problem is not that you'll lose on performance when you have too many clients - how many clients do you expect to have on a 1MB address space machine (I am intentionally leaving OS/2 out here)? You can't fit in enough to make the performance an issue here. The real problem is that if a client exits without telling the driver, the system will crash the next time a packet is received. - john
philipp@PHYSICSA.MCGILL.CA (Philip Prindeville Comp Ctr) (12/15/88)
>>I like the packet driver spec way of demultiplexing >>much more (and there really is no excuse for not doing it that >>way, either). > >That's not true. I've never been completely happy with the way >demultiplexing works in the packet driver. It doesn't work well in >cases where you have IEEE packets with SNAP headers and Xerox blue >book packets with type fields on the same ethernet. Generally, it >doesn't work well in any environment where type information does not >always start at the same place in a packet. This doesn't pose a problem -- one can have a driver program that provides two different (pseudo) devices, an Ethernet II and an 802.3 interface. An application (or at least the person configuring it) should be smart enough to figure out which one to use when speaking a certain protocol on a particular wire... >The MAC approach opens you up to whole new methods of selecting >packets - for instance, a network monitor could decide whether it >wanted the packet before allocating buffer space to it - it could >inspect every field in the packet that it cared about. Even using a >packet driver with a general bit mask that each client would register >wouldn't allow this flexibility. I think if there was a more generalized approach, such as mapping a packet into `system' space passing pointers (via indications?) to the various client processes, then this would be winning. Still, there is the overhead of having each process inspect the packet, when it should only be checked once. What would VJ say? -Philip