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