🚀 go-pugleaf

iann@bnr.co.uk (Ian Newman) writes:

>What is the difference between what you're planning to propose and what AT&T's
>TLI (Transport Library Interface) does for you at Transport Layer?

MS-DOS is not UNIX. MS-DOS has highly specific demands for interprocess
communication. Interfaces have to be defined at the memory layout level
and there are a LOT of restrictions (just remember the various 64kB
barriers in the addressing model) that have to be considered in the
interface design. So we can learn much more from established DOS
interfaces (e.g. packed drivers, NDIS, ...) than from the UNIX world.

TLI is just a collection of C functions that you can call. This is far from
all we need under MS-DOS.

Why don't I suggest to use a TLI mapping for the lower interface/cut?
Well:

My suggested architecture has 3 modules:

    1. network driver
    2. OSI driver
    3. application programm

Now let me define the meaning of these 3 modules. Let's begin with the
OSI driver. It is indented to be written only once and it should include
all the boring stuff that is independent from the lower layers and the
application. This includes at least session, presentation and ACSE. I
believe, that it includes also transport, part's of the network layer
and parts of ROSE, RTSE and BER en-/decoding. The OSI driver should include
all things that we want to develop only once.

A network driver will be necessary for each kind of lower layer stack
that we want to use (e.g. CLNP over Ethernet, CONS over Ethernet,
CONS with async X.25 over serial lines, ...). As much common functionality
as possible should be concentrated in the OSI driver, so TP0-TP4 (which
use all the same basic header format etc.) clearly belongs not in the
network driver. Also the code that decides which of several loaded network
drivers (e.g. serial line and ethernet) should be used has to be located
outside the network driver. Consequently TLI is the wrong place to start
with. The network driver/OSI driver interface has to be specified from the
network drivers point of view.

Both the network and the OSI drivershould be implemented as device
drivers (started in CONFIG.SYS) or as TSR programs. This avoids complicated
linking and makes them easy to exchange. Most other DOS networking software
that I know uses a very similar approach. Many network drivers will use even
another driver below (e.g. packet, FOSSIL) to access the hardware. All this 
will make development of applications and network drivers very easy.

Perhaps the term OSI driver should be replaced by a better name, as not the
full functionality of a 7 layer stack is implemented in this programm. E.g., 
many parts of the service specific application layer service elements (e.g.
MTS in X.400, etc.) will be part of the application program.

The interface between the OSI driver and the application program (e.g.
an X.500 user agent) might very well be based on something developped
for UNIX, at least if you use a common C library in order to access
the OSI driver. This is a real API (an interface designed from the 
application's point-of-view, not from the driver's) that should provide
the functionality (service) of ACSE, ROSE, ... It should be designed,
so that demo examples that use full ACSE, ROSE, BER etc. might be written with
less then 100 lines. This is surely possible and will be very impressive
for other public domain and commercial authors.

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
---- simply not getting the most out of life possible. (Brian Downing) ----