Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!bloom-beacon!spdcc!ftp!jbvb
From: jbvb@ftp.COM (James Van Bokkelen)
Newsgroups: comp.dcom.lans
Subject: Re: PC/IP and the Packet Driver.
Summary: Packet Driver demuxes by Ethertype; only one stack can get IP or XNS
Keywords: TCP/IP, packet driver
Message-ID: <738@ftp.COM>
Date: 13 Oct 89 14:43:21 GMT
References: <489@excelan.COM> <6635@pdn.paradyne.com> <736@ftp.COM> <6646@pdn.paradyne.com>
Organization: FTP Software Inc., Cambridge, MA
Lines: 22

In article <6646@pdn.paradyne.com>, dixon@gumby.paradyne.com (0000-Tom Dixon(0000)) writes:
> A couple of questions:  
> We have never tried this but have always wondered it. Can you use
> the packet driver with multiple TCP/IP applications?  Say for example
> NCSA Telnet and PC-NFS.  Or would the packet driver get really confused?

In the basic packet driver, the packet demultiplexing is done at the link
layer; by Ethertype in Class 1, or 802.2 header in Class 11.  Thus, there
can be only one stack getting IP packets (Ethertype 0x800) or XNS packets
(Ethertype 0x600) at any given time.  The second IP stack should get an error
on the access_type() call.  Some people at Clarkson hacked a special driver
to do demuxing at higher levels, but they may not be using it anymore.

My own opinion is that protocol stacks are too bulky to have two sets of code
doing the same thing (TCP or IP).  Our PC/TCP presents a standard programming
interface above the transport layer, as does PC/NFS, and I would suggest
porting the "Telnet and above" part of NCSA to use the other transport,
rather than introducing some IP-TPC demuxer that gets the packets where they
want to go based on the TCP port.
-- 
James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901