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

Internet Message Format | 1992-09-02 | 3.8 KB

Path: sparky!uunet!aspentec!tto
From: [e-mail]
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: TSRs and(was Re: tcp-ip library nonblocking I/O (Berkeley compatible))?
Message-ID: <[e-mail]>
Date: 2 Sep 92 13:03:19 EST
References: <[e-mail]> <[e-mail]>
Distribution: world
Organization: Aspen Technology, Inc. Cambridge, MA.
Lines: 74

In article <[e-mail]>,
[e-mail] (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                                                    [phone] x377
Aspen Technology, Inc                                Fax: [phone]
243 Vassar St, Cambridge, Ma 02139.                       [e-mail]
-----------------------------------------------------------------------------