                          nipc.library Architecture



The nipc.library is the communications workhorse and largest piece of Envoy.
It provides a Transaction-based reliable communications path between multiple
Amigas, above any compliant SANA II device.  To understand exactly where the
nipc.library fits into the broad APPN picture, one needs to have a general
understanding of the different layers that define the nipc.library and it's
interactions with others.  As a reference, please note figure A.

                                                   As figure A shows, the
                                                   nipc.library sits directly
        +--------------+  +------------+           above the device drivers
        | Envoy        |  | Stand      |           for each piece of
        | Applications |  | Alone Apps.|           networking hardware in
        +--------------+  +------------+           use, and directly below
 NIPC API----->    \         /                     either applications or
        +------------------------------+           another library.  Some
        |         nipc.library         |           applications may only
        +------------------------------+           require the ability to
 S-II Std Interface-->  |                          transmit and receive data
        +------------------------------+           reliably - and not require
        |     SANA-II Device Drivers   |           some of the more complex
        +------------------------------+           features that higher levels
                        |                          of Envoy provide.  Thus,
        +------------------------------+           these programs
        |      Networking Hardware     |           communicate directly
        +------------------------------+           with the nipc.library.

                    Figure A.

                                                   Figure B. provides a more
detailed diagram of exactly what levels make up the nipc.library, as well as
the interfaces between levels.



The lowest level is the specific networking hardware.  This could be anything
from an A2065 ethernet board to a low-speed serial link.  The only requirement
on the hardware is that a SANA II device driver must exist for it.  The hardware
communicates with the next layer up (the SANA II device drivers) through an
arbitrary hardware specific interface.  This is dependant on the exact hardware

used, and may vary from implementation to implementation (for example, two
differently designed ethernet boards will communicate with their
device drivers differently - as they            +----------------------------+
may have been designed around                   | 5      Applications        |
different chipsets).                            +----------------------------+
                                              /                |
                                              | +----------------------------+
The second level consists of one or           | | 4   NIPC "Presentation"    |
more SANA II device drivers.   Please         | +----------------------------+
reference the document "SANA-II Network    N  |                |
Device Specification", 5/5/92 for          I  \ +----------------------------+
more specific information.  The SANA II    P  < | 3        RDP & UDP         |
device drivers provide a standard          C  / +----------------------------+
interface between wildly different            |                |
networking software and networking            | +----------------------------+
hardware.                                     | | 2      IP, ICMP, ARP       |
                                              | +----------------------------+
                                              \                |
The third leve marks the beginning              +----------------------------+
of a set of two levels of the proposed          | 1      SANA-II Driver      |
design which are intentionally insulated        +----------------------------+
from the rest of the design.  (These can                       |
be seen in figure B, as levels 3 and 4,         +----------------------------+
as well as the interfaces between 3, 4, and     | 0    Networking Hardware   |
5.)  The goal in doing this is to prevent the   +----------------------------+
nipc.library from being necessarily tied
to a specific networking protocol.                        Figure B.
For instance, it's entirely
possible to create an nipc.library which is based on Novell NetWare instead of
the protocol stack shown in figure A.  Level two in figure B is similar to the
ISO 'Network' layer in most functions.  It's function is to packetize and route
data from one site to another.  This level is made up of implementations of the
internet protocol (IP), the internet control message protocol (ICMP), and the
address resolution protocol (ARP).

Above the Internet Protocol is the Reliable Datagram Protocol - which makes up
level three.  RDP provides reliability and sequencing, among other features, to
the datagram service.

Level four contains the NIPC Presentation layer.  Specifically, this level
provides the services specified in the nipc.library Autodocs, based on the
services provided to it by lower levels (RDP and level four, in this instance).
Communication to the next higher level is provided through the interface
defined in the previously mentioned standard.

While a layered model is an excellent method by which one may understand
networking protocols, it's a decidedly poor way to implement a protocol stack.
In light of this, levels two, three, and four are not entirely distinct.
Communication between these levels is done with a buffering scheme that's
designed to minimize data copying.

The library itself contains everything from the SANA II interface up
through the NIPC API (this is shown bracketed on figure B).


