From: eengelke@sail.uwaterloo.ca (Erick Engelke)
Subject: Re: TSRs ...
Organization: University of Waterloo
Date: Fri, 4 Sep 1992 19:09:49 GMT

Sorry for beating this into the ground, I wonder how many people are
still interested...  I have no intention of knocking any vendors or
products, all provide similar functionality but through different means.

Included is some technical information for the people like Bob Baggerman
and Edmund Sutcliff who've asked about the low level interfaces to PC-NFS.

geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>Quoth tto@aspentec.com (in <1992Sep3.121205.863@aspentec.com>):
>#eengelke@sail.uwaterloo.ca (Erick Engelke) writes:
>#> tto@aspentec.com writes:
>#
>#>>Another nice thing about FTP's PC/TCP package is that it allows an easy
>#>>access to the global file descriptors.  With other packages one has
>#>>to do more work in order to share a descriptor among several applications.
>#> 
>#> Yes, most of the others require you to change your PSP back to the 
>#> originator's.  That's easy enough when they provide source, but the 
>#> one's that don't are a true headache because you have to reverse engineer 
>#> or run through hoola hoops just to do shared access.  
>
>In the case of PC-NFS, the reason you have to switch to the owner's
>PSP is because our socket handles are real file descriptors - you can
>read and write them using DOS calls. 

Yep.  I'm almost afraid to summarize, but here goes:

Sun's PC-NFS, Beame&Whiteside, Novell LWP and a few others support a
direct mapping into the file space which means you can use DOS read
and write code, in fact you can use C's read() and write().  If
working under a TSR, you must first set the PSP to the TSR's PSP,
call DOS, and reset the PSP back to its previous state.  If the 
socket was openned by another program, you will have to use ITs
PSP and not the TSR's.  This is easy enough for read and write,
but what about other functions...

I hate trying to go from memory, but am nowhere near my notes.
Functions like select() are performed by calling DOS's fn 44H, ioctl
services, subfunctions typically correspond to those of the documented
DOS fn 44H.  

The trick of doing the socket(), bind(), etc. is less obvious.

Writing to the BSD library is often easier, says the man with umteen
different versions for each of the network stacks he must support,
but writing directly to the TCP interface makes smaller, faster TSRs
and that's what people pay for.  

It's possible with other vendors' stacks, but only FTP, B&W and 
a few others seem to still document the core interface.  Beame&Whiteside and 
Essex offer FTP compatibility, so you can also use that documented 
FTP core interface.  But for the few of us who really need small size,
it remains an exercise in debugging to write a small tsr for the other 
stacks and still have complete TCP functionality (not just
a TELBIN or BAPI or similar subset).

I would be very happy to hear I'm wrong and that the others have released
information on the lower layers, or source code to the interface layer
as do B&W and FTP.

>(When you referred earlier to
>FTP's "global file descriptors" you should have called them "private
>non-file socket descriptors".) 

Of course you are correct.  I know how difficult it was to write your 
end, and have used the various stacks  in situations which have 
benefitted from the file interface.  If only the documentation were
there to help promote that useful interface.

Erick
-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca