Path: utzoo!utgpu!attcan!uunet!husc6!think!bloom-beacon!tut.cis.ohio-state.edu!mailrus!purdue!decwrl!ucbvax!TWG.COM!jb
From: jb@TWG.COM (John Bartas)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Sharing Interfaces
Message-ID: <8808031726.aa26309@Louie.UDEL.EDU>
Date: 3 Aug 88 21:09:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 49


     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.