randy@LARRY.CS.WASHINGTON.EDU (Randy) (07/23/88)
It is my understanding that in order to share a network interface between,
say, Netware and PC/TCP that both packages need to cooperate via the
Packet Driver Spec. In other words, it's not enough for just one package
to access the interface via the Packet Driver Spec.
Is this correct?
Randy Day.
Internet (ARPA): randy@cs.washington.edu
CSNET: randy%washington@relay.cs.net
UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randyjac@UMD5.UMD.EDU ("Joseph A. Cimmino Jr.") (07/23/88)
> It is my understanding that in order to share a network interface between, > say, Netware and PC/TCP that both packages need to cooperate via the > Packet Driver Spec. In other words, it's not enough for just one package > to access the interface via the Packet Driver Spec. > Is this correct? That is also my understanding, each application ( in this case, both Netware and PC/IP ) need drivers that talk a "Packet Driver Spec". There then needs to be a piece of code supplied ( by the hardware vendor? ) that implements the "Packet Driver Spec." for a particular board. ------------------------------ Joseph A. Cimmino, Jr. University of Maryland, Systems jac@umd5.umd.edu +1 301 454 2946 PC/IP Group cimminoj@umdd.bitnet Bertolt Brecht: You made your bed, so you lie in it.
jbvb@VAX.FTP.COM (James Van Bokkelen) (07/24/88)
Both the LAN program (Netware) and any other network program (TCP/IP) need to cooperate, via some interface-sharing mechanism. Otherwise, they fight for the interrupt vector, throw away each other's packets, etc. The Packet Driver spec is one such interface sharing mechanism. In summary, your understanding is right. James VanBokkelen FTP Software Inc.
jb@TWG.COM (John Bartas) (07/28/88)
The recent postings about Sharing Interfaces have made me
curious: which Packet Driver Spec are we talking about? 3COM,
Novell, FTP Software Inc., and others have published details of
their network hardware interfaces, but I have yet to see one that
meets my needs as an implementor.
For a packet driver spec to succeed, it needs several
things:
- Wide acceptance by Software and Hardware Vendors.
- The ability to support multiple protocol stacks
simultaneously.
- The ability to drive multiple interfaces simultaneously.
3COM's and Novell's current products detail procedure calls to
access the hardware, but they expect the application code to be
linked with the driver code. There is no provision for me to
write an application that will load in a DOS PC already running
their networking and directly access the ethernet (or whatever)
via their driver.
Drivers written to FTP software's spec allow this, but my
understanding of their spec is that it does not support multiple
interfaces simultaneously. This won't work for routers and multi-
homed hosts.
One solution to sharing drivers is to let one software
package's driver layer use the other package as a link layer.
This assumes that the other end on each connection is a similarly
configured machine or that there is a gateway which has one
interface similarly configured. On most PC LANs, this turns out
to be a reasonable assumption. For example, Wollongong's
WIN/Route product connects PC LANs to TCP/IP nets by using
NETBIOS as a link layer between PCs and dedicating a single PC to
routing packets to a regular TCP/IP link. One advantage of this
approach is the TCP/IP software doesn't care what hardware or
software it runs on, as long as it supports NETBIOS.
3COM has announced their Vector interface as part of LAN
manager will be available on DOS and OS/2. Vector has been
evolving for years and seems to meet the criteria I set above. I
imagine the other major vendors of PC Networks will introduce
similar standards and the industry will settle down to the few
most widely accepted ones.
---------------------------------------------------------------
John Bartas Project Leader - The Wollongong Group.jbvb@VAX.FTP.COM (James Van Bokkelen) (07/29/88)
When Phil Karn, Russel Nelson, Karl Auerbach or I (at least) say "Packet Driver spec", we mean the one FTP Software has published. 3Com calls their linked-in libraries "3L", and the upcoming Protocol Manager spec "MAC/Vector". I haven't heard anything about Novell's, let alone a name. FTP's Packet Driver spec does allow multiple interfaces in a machine, but only one per interrupt. The spec says that you are supposed to scan a range of vectors, looking for one that points at a JMP followed by a particular string. If you don't like the one you find, or want more than one, you can keep on scanning. The only limit on the number of vectors is the size of the range you scan (32 vectors, 0x60 to 0x7F). 3Com/Microsoft have lots of clout, but the MAC/Vector interface is not on the streets yet. Furthermore, it had several aspects that I consider severe problems the last time I looked (it was being actively revised as of May). 1. You do all of your binding (setting up handlers for incoming packets) at CONFIG.SYS time, so you can't use many DOS (or OS/2) services while starting your protocol modules. 2. You cannot un-bind, ever. No transient network protocols built into programs, no un-loadable protocol TSRs. Instead, you have to edit a file & reboot if you need more memory to run your CAD program or whatever.... 3. Rather than telling MAC/Vector what kind of packets you want, instead it goes down its list of handlers, asking them one after another "do you want this packet". This means that there is no possibility of arbitration (or even error detection) when two applications want the same type, and opens the door for "badly behaved applications" to screw things up for the rest of us. The Packet Driver spec has some problems, too, but it can and will be revised (with input from many people using it in different ways) while remaining backwards compatible. MAC/Vector might be revised as well, but I don't think I'll see any of my objections dealt with (except maybe a one-shot 'unbind', with no possibility of a 're-bind'); the others seem pretty organic to the design of the thing. James VanBokkelen FTP Software Inc.
jb@TWG.COM (John Bartas) (08/04/88)
Opps, Sorry! A couple of people pointed out to me ways that
FTP's Packet Driver Spec *CAN* support multiple interfaces
simultaneously. I stand corrected.
James Van Bokkelen also made some good points about 3Com's
MAC/Vector interface. I think some further discussion is
warranted since this may be widespread when Lan Manager finally
gets here.
Lan Manager was announced with OS/2 and supporting it on DOS
seems to have been an afterthought. Thus it's not too suprising
that the problems with initialization and permanant binding James
mentioned are less serious under OS/2 than DOS. The last problem
he mentioned, however, could be considered a feature. He wrote:
> 3. Rather than telling MAC/Vector what kind of packets you want, instead
> it goes down its list of handlers, asking them one after another "do you
> want this packet". This means that there is no possibility of arbitration
> (or even error detection) when two applications want the same type, and
> opens the door for "badly behaved applications" to screw things up for
> the rest of us.
This is all true; and additionally having several applications
peruse each packet before giving it to the one that wants it
could seriously slow performance for the applications at the end
of the list. But having MAC/Vector demux the packet between
protocols based on a type field can get pretty complex when you
consider how the offset, values, and size of the type field can
vary. Putting this burden above the Vector layer allows things
like two IP stacks co-existing, or a single driver processing
Ethernet and 802.3 packets. It would generally be easier to
implement complex algorithms for packet acceptance. "Badly
Behaved applications" could be put at the end of the list of
handlers by the users once they are identified as such.
One of the benefits of any packet driver spec becoming a
standard is that hardware makers hopefully will release
conformant drivers with their hardware products, freeing software
companies of the burden of coding new drivers. If MAC/Vector
becomes such a standard, it may be feasable to implement a layer
above it that emulates FTP software's Packet Driver Spec. It may
also be usefull to have the reverse: software mapping MAC/Vector
calls into Packet Driver Specifications. Such layers tend to make
things bigger and slower, but it's better than no connectivity at
all.
-----------------------------------------------
John Bartas - Project Leader
The Wollongong Group.philipp@LARRY.MCRCIM.MCGILL.EDU ("Philip A. Prindeville") (08/05/88)
of the list. But having MAC/Vector demux the packet between protocols based on a type field can get pretty complex when you consider how the offset, values, and size of the type field can vary. Putting this burden above the Vector layer allows things But what are SAPs for, anyway? The driver should know the offset and size of the SAP, as well as how to interpret it. And you can't argue about Ethernet vs. 802.3 because... like two IP stacks co-existing, or a single driver processing Ethernet and 802.3 packets. It would generally be easier to It is possible for a single driver to "register" multiple interfaces. (Just as under DOS a single driver can register multiple device headers). There is even a differentiation amongst the various types of Ethernet in the documentation (it is at home right now, but I remember there were "802.3", "802.3+DIX" [?], "Ethernet", etc). An protocol stack, such as IP, must be aware of whether it is binding to 802.3, ethernet, token ring, pronet, arcnet, etc. Indeed, since it doesn't have to worry about driving the device, it can transfer the complexity (conservation of complexity) to speaking multiple MAC flavours (a protocol stack, that is). One of the benefits of any packet driver spec becoming a standard is that hardware makers hopefully will release conformant drivers with their hardware products, freeing software companies of the burden of coding new drivers. If MAC/Vector Yes, even if MAC/Vector isn't a *great* spec, it still beats having to write device drivers over-and-over... Lastly, supporting DOS 3.X wasn't worth the trouble. There isn't enough memory to make having multiple applications resident feasible, so why restrict yourself to it? The same with real- memory mode. Is anyone *really* going to both? If I have a 386, I'm going to damn well use it like a 386... -Philip
philf@med-isg.uucp (Phil Fernandez) (08/06/88)
In article <8808050336.AA06496@Larry.McRCIM.McGill.EDU> philipp@LARRY.MCRCIM.MCGILL.EDU ("Philip A. Prindeville") writes: > > <some good points about MAC/Vector omitted> > >Lastly, supporting DOS 3.X wasn't worth the trouble. There isn't >enough memory to make having multiple applications resident >feasible, so why restrict yourself to it? I disagree with this entirely. 3Com told me this same thing. There are some *very* valuable applications under DOS, at least in our environment. For example, we often want to FTP a file to/from a 3Com virtual drive. This would easily run in 640K. Supporting DOS would definitely be worth the trouble! pmf