Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!FTP.COM!gordon
From: gordon@FTP.COM (Gordon Lee)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re:  BW-NFS, working with Packet Drivers and other software.
Message-ID: <9104111956.AA16734@ftp.com>
Date: 11 Apr 91 19:56:55 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: gordon@ftp.com
Organization: The Internet
Lines: 29


    From: Stu Donaldson <fluke!gtisqr!stu@beaver.cs.washington.edu>
    Subject: Re:  BW-NFS, working with Packet Drivers and other software.
    
    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?
    
The packet driver as spec'd has no *active* control over which application 
gets traffic of a given protocol type.  It only responds to the requests
of the applications above it.  Once a particular application hooks a
particular protocol type, the packet driver is not able to tell it to let go.

The Packet Driver Spec has two calls "access_type" and "release_type"
which allow the application to hook or unhook a particular protocol
type.  The closest you could get would be to have the applications 
temporarily relinquish control over the protocol in question through 
a release_type call and then reissue an access_type call later on.

As a case in point, the only way to make the PC/TCP kernel
relinquish control is to unload it.  It issues an "access_type" on
startup and a "release_type" on shutdown.  I don't know off hand what 
other existing applications do.

== Gordon Lee                 FTP Software Inc
== voice: (617) 246-0900      26 Princess St
== fax:   (617) 245-7943      Wakefield, MA  01880