From: tto@aspentec.com
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: TSRs and(was Re: tcp-ip library nonblocking I/O (Berkeley compatible))?
Date: 2 Sep 92 13:03:19 EST
Distribution: world
Organization: Aspen Technology, Inc. Cambridge, MA.

In article <Btx5J4.2tD@watserv1.uwaterloo.ca>,
eengelke@steam.uwaterloo.ca (Erick Engelke) writes:

>...
> ... Every DOS based TCP implementation has 
> had to deal with the seemingly innumerable problems of fitting everything
> into a TSR and dealing with DOS's memory/file services and the lack
> thereof.  What does that mean?  They cannot allocate buffers on the
> fly, they cannot necessarily do DOS i/o due to the re-entrancy of DOS,
> and mapping tcp/ip i/o directly into the filespace (like unix does) 
> is possible in part, but not fully.

How true.

> So all the popular TCP systems use a low-level homegrown API to do the
> real communication between user applications and the TCP/IP kernel,
> but they hide this layer underneath a BSD 4.1 or 4.3-ish set of function
> calls.
> 
> Many products only provide the BSD-ish layer for external developers, 
> that encourages them to use only documented facilities and makes the
> product look nice so the TCP author doesn't look like he had to make
> the kludges that are actually so necessary.  
> 
> But in doing so, these products force TSR developers to link in 
> extra bulky functions, and in the case of at least one library, 
> use a malloc(), a definate no-no in tsr development!

Yes, many developers have no idea how to do things properly in the DOS
environment, let alone making programs suitable for a TSR.  E.g., Sun's
PC/NFS uses malloc() and DEC's Pathwork TCP/IP (written by 3Com) traps
INT 2F (AX=1122) and promptly undoes itself whenever one issues an
INT 21 (AH=31) to terminate and stay resident!

> The solution?  FTP provides their BSD environment (with source which
> maps it to their internal api)  and documents their internal API too.  
> That tries to make everyone happy.  
> 
> Their internal API can be called practically any time.  
> Compeditors systems which only provide the BSD-ish interface 
> can rarely be called during DOS i/o, and sometimes have difficulty
> when called during interrupt calls.  

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.
(By the way, sharing file descriptors is one of the few things that can
be done more easily on DOS than on Unix.)

> I've done TSRs with many of the network stacks, using BSD and
> internal APIs.  Here's my advice:
> 
> 	If you are developing a non-TSR: stick to the BSD interface,
> 	it buys you compatibility.
> 
> 	If you are doing a TSR: use the lowest level interface you
> 	can find for each vendor's product, and be prepared to do
> 	a lot of debugging.  Or hire someone else to do the dirty
> 	work... 

I have a slightly different opinion on this.  I have also done TSRs
with several of these network stacks myself and I found that the BSD-ish
interface is uniform enough so that I can use the same source code (with
a few #ifdef's) for the high level stuff.  I would, however, watch
very carefully at the backend to make sure that they are not doing anything
unkosher such as allocating DOS memory.

Tak.
-----------------------------------------------------------------------------
Tak To                                                    (617) 497-9020 x377
Aspen Technology, Inc                                Fax: (617) 497-7806
243 Vassar St, Cambridge, Ma 02139.                       tto@aspentec.com
-----------------------------------------------------------------------------

Newsgroups: comp.protocols.tcp-ip.ibmpc