stu@mav.com (Stu Donaldson) (04/06/91)
We recently purchased a copy of BW-NFS for evaluation. I am having problems getting this to work with other programs that want to talk to the network board. I am useing a WD8003E card, and have also tried the 8.7 version packet driver. The other software I am trying to run, is NCSA_Telnet, and it's related programs. I also plan on running some Email software in the future. Does anyone know how this can be done short of porting the other applications to use the socket library available from Beame and Whiteside? Any help would be appreciated. Please respond via email -- Thanks -- ----------------------------------------------------------------------- Stu Donaldson "Can't you understand what I'm saying?" stu@mav.com "What happened? Did you Fail Telepathy?"
fks@FTP.COM (Frances Selkirk) (04/08/91)
Stu Donaldson <fluke!gtisqr!stu@beaver.cs.washington.edu> > We recently purchased a copy of BW-NFS for evaluation. I am having > problems getting this to work with other programs that want to talk > to the network board. I am useing a WD8003E card, and have also > tried the 8.7 version packet driver. The other software I am trying > to run, is NCSA_Telnet, and it's related programs. I also plan on > running some Email software in the future. > > Does anyone know how this can be done short of porting the > other applications to use the socket library available from Beame > and Whiteside? Hello, everybody. This is your monthly post, saying: ("YOU CAN ONLY RUN ONE TCP/IP STACK AT A TIME OVER A PACKET DRIVER.") Packet drivers sort packets by protocol type. They do not duplicate packets for delivery to two stacks of the same type. The first stack will get the packets; the second stack will starve. If you wish to run other TCP/IP apps simultaneously with BW-NFS (or any other TCP/IP package), port them to the programmers' interface. Better yet, if possible, find a single package that satisfies your needs for telnet, email and NFS. (Apologies to Arlo Guthrie for the format of the second sentence.) Frances Kirk Selkirk info@ftp.com (617) 246-0900 FTP Software, Inc. 26 Princess Street, Wakefield, MA 01880
stu@mav.com (Stu Donaldson) (04/11/91)
In article <9104081632.AA04236@ftp.com> fks@FTP.COM (Frances Selkirk) writes: > >Hello, everybody. This is your monthly post, saying: > > >("YOU CAN ONLY RUN ONE TCP/IP STACK AT A TIME OVER A PACKET DRIVER.") > > >Packet drivers sort packets by protocol type. They do not duplicate >packets for delivery to two stacks of the same type. The first stack >will get the packets; the second stack will starve. > >If you wish to run other TCP/IP apps simultaneously with BW-NFS (or any >other TCP/IP package), port them to the programmers' interface. Better >yet, if possible, find a single package that satisfies your needs for >telnet, email and NFS. 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? -- Stu -- ----------------------------------------------------------------------- Stu Donaldson "Can't you understand what I'm saying?" stu@mav.com "What happened? Did you Fail Telepathy?"
gordon@FTP.COM (Gordon Lee) (04/12/91)
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 01880erick@sunee.waterloo.edu (Erick Engelke) (04/12/91)
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
jbvb@FTP.COM ("James B. Van Bokkelen") (04/12/91)
Is there a way to temporarily unload or put on hold, the main application? There is presently no such "hold" call in the Packet Driver spec. The PC/TCP TSR module can be unloaded from the keyboard, allowing other IP-using packet driver applications to run, but I don't think our competitors support this. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
nelson@sun.soe.clarkson.edu (Russ Nelson) (04/12/91)
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?
Sure. Just hack at the packet driver skeleton so that it doesn't check
to see if a type is already in use, and force the type search to be
most-recent-first.
But that's still not going to solve *all* your problems. What happens
if TCP2 tries to communicate with a host that TCP1 was communicating with?
Most likely, the TCP1 connections will get shut down. Yes, the user can
avoid doing that, but I certainly wouldn't want to explain that restriction
to all of my users.
If you make this change, remember that the copyright on the Clarkson collection
of packet drivers requires that you prominently state that changes have
been made. No way do I want to get any questions on *this* puppy...
--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.