jbvb@VAX.FTP.COM (James Van Bokkelen) (08/03/88)
From tcp-ip-RELAY@SRI-NIC.ARPA Tue Aug 2 18:53:00 1988 Received: by vax.ftp.com id AA29120; Tue, 2 Aug 88 18:53:00 EDT Received: from ucbvax.berkeley.edu by SRI-NIC.ARPA with TCP; Tue, 2 Aug 88 05:35:14 PDT Received: by ucbvax.berkeley.edu (5.59/1.28) id AA02380; Tue, 2 Aug 88 05:31:05 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Aug 88 23:25:49 GMT From: microsoft!jonsm@beaver.cs.washington.edu (Jon Smirl) Organization: Microsoft Corporation, Redmond, WA Subject: Re: Microsoft MAC/Vector interface Message-Id: <1670@microsoft.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa | 1. You do all of your binding (setting up handlers for incoming packets) | at CONFIG.SYS time, so you can't use many DOS (or OS/2) services while | starting your protocol modules. At OS/2 config.sys time a driver can actually do an awful lot *more* than it can after config.sys time. This is because it is running at ring 3 at that time and can do file i/o for example. After init, all driver code is ring 0 and can't do any os services except devhlps. If the above remark is really about wanting to write protocol code to live at ring 3, this can actually be done within the present structure--see the response to point 2 below. Note that we will in the future be extending the protocol manager to add dynamic binding and unbinding. The current bind command logically can do that today; all that is missing is the unbind command and a way to ask the protocol manager to issue a binds and unbinds at run time. In fact, the version 2 protocol manager spec will allow for several run time functions, including dynamic binding, unbinding, and query/change module config settings. Ring 3 APIs to the protocol manager will let applications invoke these services. | | 2. You cannot un-bind, ever. No transient network protocols built into | programs, no un-loadable protocol TSRs. Instead, you have to edit a file | & reboot if you need more memory to run your CAD program or whatever.... See note about our planned bind/unbind extensions above. Regarding transient protocols--on OS/2 you can do this by writing a stub protocol module that interfaces to a ring 3 protocol daemon. The daemon would ioctl threads down to the stub to get requests and pass back responses--or better, ioctl down the address of a shared memory area where request queues could be managed between ring 0 and 3. A similar thing could be done on DOS 3. Regarding unloading TSRs--again using the stub protocol module, you could bring in the actual protocol code as an EXE which certainly could terminate and free its memory. Regarding "editing a file" to reconfig: there is no requirement for a module to take its config from protocol.ini, or to do it only at boot time. Modules can use private means to get config, including doing it dynamically at run time via ioctls to the driver or whatever. Modules can be written to even resize themselves when run time reconfig happens--ie, if they dynamically allocate their buffer space, or have an app-level daemon do this for them. (All this is saying is that if you are creative you can even get the effect of dynamic reconfig sooner than when we provide a standardized way for doing it). | | 3. Rather than telling MAC/Vector what kind of packets you want, instead | it goes down its list of handlers, asking them one after another "do you | want this packet". This means that there is no possibility of arbitration | (or even error detection) when two applications want the same type, and | opens the door for "badly behaved applications" to screw things up for | the rest of us. | We considered providing a way to provide packet dispatch info to the vector, but providing adequate flexibility here was far more complexity and overhead than seemed justified by the need. What does it mean to tell it "what kind of packet you want"--do you specify what the source address should be, or destination SAP, or both, or some bit masked address compare, or do you also want to include specific packet command codes, or protocol type bytes, or other compare conditions, or what? Cases can be made for all these and more, and that just leads to absurd complexity for a little-needed function. In general it is a "configuration error" to have two drivers installed that would conflict over what packets they want; indeed, all that a complex descriptor mechanism would do is let you detect this configuration error. That would be nicer than not detecting it, but again, the amount of overhead to detect this rather unusual error condition did not appear justified. The current polling scheme works just fine for what we believe the 99% case to be--protocols sharing a mac where the conflicts don't arise. We are interested in any concrete suggestions on what a better solution would be, or why there is some important need not addressed by the current solution. microsoft!jonsm