Newsgroups: comp.protocols.tcp-ip.ibmpc
Path: utzoo!utgpu!watserv1!sunee!erick
From: erick@sunee.waterloo.edu (Erick Engelke)
Subject: Re:  BW-NFS, working with Packet Drivers and other software.
Message-ID: <1991Apr11.232800.25911@sunee.waterloo.edu>
Keywords: bw-nfs, packet, tcp/ip
Organization: University of Waterloo
References: <9104081632.AA04236@ftp.com> <1991Apr11.141125.27490@mav.com>
Date: Thu, 11 Apr 1991 23:28:00 GMT
Lines: 63

In article <1991Apr11.141125.27490@mav.com> stu@mav.com (Stu Donaldson) writes:
>
>Is there a way to temporarily unload or put on hold, the main application?
>Essentially block that application from the packet driver, and start
>up some other application such as an email package, then enable the
>main application again?  Possibly an alternate packet driver interrupt
>vector that when in use, would cause the primary vector to be on hold?
>

There are a number of ways to attack this and a number of arguments to use.
Please send comments to me rather than the group because I am just glossing
over some of the impracticalities. 

Assuming the new packet driver processes the packet and does not pass it on
to the old one, the answer is... No.  Many  systems still use keep alives
or would have some other sort of activity which would kill sessions you might
have going already.   You would have to close ALL TCP sessions first which
is different from putting them on hold which was your original request.

You might think, "well, why not pass the packet on to the other packet driver
or sessions?  Wouldn't that keep existing sessions alive?".  First of all, you
could probably not have multiple active packet drivers because they each controlthe hardware.
But let's assume your single packet driver passed the packet to each TCP.
That idea would possibly work except that each other TCP system
would send a RESET  or an ICMP death threat because they each think they have
sole control of the IP address and the incomming packet was unacceptable.
They are required by RFC law to complain.  You would also be having them
receiving things they never requested and potential port conflicts and 
more problems than you could immagine.

Finally, you might think yourself capable of looking at the last paragraph
and saying, "hey, I could just filter out those resets and ICMP's and
intelligently control several TCPs." I don't want to think of the consequences.
It would be too flaky a system to use.

If you were to use a second IP number for the new TCP, you could actually do
the sorting  at the packet driver level.  I have had to do this and so I can
say that it can work except for RARP.  Quite simply, for incomming IP packets
you determine the IP interface from the destination IP field.  For broadcasts,
you submit the packet to each kernal.  Please note, I said it CAN work, not
that it will.  As soon as possible, I removed this kludge because it was doomed
to fail at some point.

As several people have stated many times, the packet driver interface is not
the appropriate mechanism for supporting multiple TCPs.  In fact, multiple
TCP kernals are also not very good.  What we really need is a single API (that
means Application Programmers Interface, the glue between a TCP stack and an
application program which is currently different for each commerical stack)
which will allow vendor-independant software to execute on any TCP stack.

I have asked this group for comments on such an API and have received some
good responses.  Some individuals in one of the most influential TCP firms
have offerred some comments and suggestions.  Please realize I am not saying
you could necessarily run, say, Wollongong's NFS over Beame and Whiteside's 
stack, but it would mean a vendor or author could make a program or a version
of a program which could operate on any PC TCP stack.

Erick
-- 
----------------------------------------------------------------------------
Erick Engelke                                       Watstar Computer Network
Watstar Network Guy                                   University of Waterloo
Erick@Development.Watstar.UWaterloo.ca              (519) 885-1211 Ext. 2965
