NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/protocol/tcpip/ibmpc/5062

Text File | 1992-09-04 | 3.9 KB | 86 lines

Newsgroups: comp.protocols.tcp-ip.ibmpc
Path: sparky!uunet!utcsri!torn!watserv2.uwaterloo.ca!watserv1!sail.uwaterloo.ca!eengelke
From: [e-mail] (Erick Engelke)
Subject: Re: TSRs ...
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: University of Waterloo
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 4 Sep 1992 19:09:49 GMT
Lines: 74

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.

[e-mail] (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>Quoth [e-mail] (in <[e-mail]>):
>#[e-mail] (Erick Engelke) writes:
>#> [e-mail] 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         [e-mail]