ssw@cica.cica.indiana.edu (Steve Wallace) (06/11/90)
My goal is to get the packet driver/NetWare/telnet combo to work with Desqview/windows/WP office What if (no, this is not an HP ad) the packet drivers were modified to do following: When the function access_type is called, the packet driver makes a copy of the first 16 bytes of memory pointed to my receiver. This would be used as a signature for that receiver function. When the receiver function was called by the packet driver and when the packet driver copies the packet to the buffer, the packet driver checked the receiver's signature. If the signature is incorrect the packet driver pauses, then checks again. This idea begs the $64,000 questions; is it possible for the receiver code to be swapped out between the time the packet driver checks the signature and executes the receiver function (would disabling interrupts help?). Please let me know what you think, Steven Wallace Indiana University wallaces@ucs.indiana.edu
PIRARD@BLIULG11.BITNET (Andr'e PIRARD) (06/12/90)
On Mon, 11 Jun 90 16:29:39 GMT Steve Wallace said: >My goal is to get the packet driver/NetWare/telnet combo to work with >Desqview/windows/WP office DESQview is a tremendous multitasking tool indeed. An enhancement of the packet drivers would be most welcome. Now that we have promiscuous mode, it's regrettable that demultiplexing at the link level can only be afforded with TSR (e.g. why not NETWATCH in an other DV window?). More, could not a simple cooperative strategy demultiplex at the socket level? >I'd like to propose an enhancement to the packet driver spec. Those of >us who use multi-taskers (Desqview, Windows, etc) are not able to >cleanly use Novell netware and other network software at the same time. >The netware shell can't be loaded in a window, therefore the packet >driver must be loaded before the multi-tasker. Applications like telnet >will run in a window, but if there are other applications running in the >background, telnet will eventually hang. The packet driver is executing >the function pointed to by receiver, but the real receiver is paged out. >When the receiver function was called by the packet driver and >when the packet driver copies the packet to the buffer, the packet >driver checked the receiver's signature. If the signature is incorrect >the packet driver pauses, then checks again. No, this will not work. Simply because the receiver can be in another memory bank, because receive() -- and upcall() if I understand correctly -- occur at hardware interrupt time, when another application can be running. Application context switching must be done. The correct way should be to schedule a second level interrupt (with GETBIT/SETBIT) that finally does a PGMINT that will be forced to execute (asynchronously) in the correct environment (look in DESQview API manual, but also check this pure theory with Quarterdeck!). Only then can a packet driver be loaded before DESQview, outside an application, and shared. Under DESQview, communication programs should be non-swappable (to disk); I guess the previous scheme would work even then, if the driver is prepared to accept a (longer) delay of the final asynchronous interrupt. Now, multiple stacks for the *same* network protocol would be nice too. The correct solution would be a DESQview-aware socket interface, but would need extensive changes to packet-level TCP/IP applications. I am far from a TCP/IP guru, but I guess this could be solved in a simpler way if the packet driver had additional functions to help applications not allocate duplicate sockets and not send a reset in reply to a datagram sent to someone else's socket. Andr'e PIRARD SEGI Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) PIRARD@BLIULG11 on EARN alias BITNET pirard@vm1.earn-ulg.ac.be from Internet