dixon@gumby.paradyne.com (0000-Tom Dixon(0000)) (10/13/89)
In article <736@ftp.COM> jbvb@ftp.COM (James Van Bokkelen) writes: > As of this moment, the following TCP/IPs for DOS support the Packet Driver >and interface-sharing with BYU Netware (in order of introduction): > >FTP's PC/TCP (commercial) >CMU version of PC-IP (public-domain; Karl Auerbach's TRW driver was the first) >Phil Karn's KA9Q (no-commercial-use copyright) >Clarkson version of NCSA (public-domain) >WIN/PC from Wollongong (I'm not sure if this is commercially available yet). >PC/NFS from Sun (not supported by Sun, but available via Clarkson). 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? >If there weren't at least some people out there who think they're getting what >they pay for, I'd be in another line of work.-- Good point. Quality is worth something. But sometimes, its sweat and not cash. >James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 >FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 Tom Dixon AT&T Paradyne, Largo, Flj uunet!pdn!dixon
romkey@asylum.SF.CA.US (John Romkey) (10/13/89)
In article <6646@pdn.paradyne.com> dixon@gumby.paradyne.com (0000-Tom Dixon) writes: >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? No. The packet driver was designed to allow multiple protocol stacks to share a network interface, and to hide the hardware details of the interface from the protocol stacks. It was NOT designed to allow multiple instances of one protocol stack run on top of it. Aside from demultiplexing problems, there are all sorts of IP worms you're opening yourself up for if you try to run multiple IP stacks on one interface. -- - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com "Live the life you love, Use a god you trust, and don't take it all too seriously." - Love & Rockets
jbvb@ftp.COM (James Van Bokkelen) (10/13/89)
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
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (10/13/89)
In article <6646@pdn.paradyne.com> dixon@gumby.paradyne.com (0000-Tom Dixon) 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? The packet driver interface that I shipped off to Clarkson was very basic: it grabs all incoming packets rather than filtering on packet types. Modifying it to do static filtering (i.e. all ARP, RARP, IP) is pretty trivial. (This is what's needed for coexistence with NetWare or other non-IP stacks.) Modifying it for dynamic filtering based on individual UDP or TCP ports, etc. is _much_ harder, and in general not particularly useful: how, for example, do you persuade NCSA Telnet to use a TCP port which doesn't clash with one used by a PC-NFS Toolkit app? Geoff Arnold, Internet: geoff@East.Sun.COM PCDS Group, Sun Microsystems Inc. --------------------------------------------------------------------------- "Who's next?" "Me, doctor?" "No, ME doctor, YOU patient." (Graham Chapman, RIP)
nelson@sun.soe.clarkson.edu (Russ Nelson) (10/14/89)
In article <738@ftp.COM> jbvb@ftp.COM (James Van Bokkelen) writes: 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. Right, we're not using it anymore. We did it so that we could run RVD and NCSA Telnet at the same time. It worked, but it was kind of gross. My own opinion is that protocol stacks are too bulky to have two sets of code doing the same thing (TCP or IP). I agree. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Live up to the light thou hast, and more will be granted thee. A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.