@chapter System Architecture
@label[chapter-doc-architecture]
@cindex[architecture]

Lambda LISP machine systems provide Local Area Network (LAN) interconnection
via Ethernet using the Transmission Control Protocol (TCP) and/or
the MIT Chaosnet protocol.

With Release 4.0, both protocols are provided on either of two (optional product)
hardware interfaces.
Chapter @ref[chapter-architecture] explains
the relationship between the LISP processors and hardware interfaces
used by the networking software.
@ref[figure-architecture] is an expanded diagram
of the communications architecture for release 4.

@fullpagefigure
@setq figure-architecture figure-page
@tex
     \special{:saved-paint-image "it:keith.release-4;paint-net-rel4.qfasl"
		:magnification 2
		:h-offset 120.
		:v-offset (+ :pixel-v 150)
		}
@vskip 6in
@end tex
@caption Example: Lambda-2x2-Plus Configuration
@end(fullpagefigure)

This chapter provides some additional detail concerning the software architecture and
a general overview of both Chaosnet and TCP/IP.

@section Background

The Chaosnet protocol originated in the MIT Artificial Intelligence laboratory,
where it was implemented on a number of host system types, including
the early LISP machines developed there.
Chaosnet has been an integral part of LISP machine software for many years,
and is supported by several vendors.
The focus of development was to provide deeply embedded and user-friendly communication functions
that supported the needs of developers (such as LISP programmers)
working on a local area network (such as in a research environment).
A great deal of functional elaboration is dependent on or tightly attached to
the protocol.
For example, central to the Chaosnet protocol is the concept of
"transparent access".
On the LISP machines running Chaosnet, users can, for example, specify filenames
usinga syntax approximating that of the remote host;
the local host provides pathname parsing capabilities.
Most utility functions are expected to deal with any recognizable pathname type.

TCP/IP protocols evolved in a fairly secure mainframe environment, where hosts
of various types might be separated by large distances.
These protocols were not designed for the degree of file sharing
permissible on local area networks, or the programming and file manipulation
styles that were developed around LISP machines.

Nonetheless, TCP/IP is a very popular protocol, given the wide range of
host type implementations and the rigorous specification as endorsed for DOD use.
The goal of networking on the Lambda, therefore, is to provide "the best of both worlds":
the transparent features of file access to any recognized host type,
the tightly coupled programming features provided by Chaosnet,
and the wide availability to TCP-compatible hosts.
To the greatest possible extent, the release 4 networking software
attempts to use the best protocol access method available for the given task.

@section Services and Functionality

The table in @ref[figure-chaos-protocols] lists the features provided by Lambda Chaosnet.
@ref[figure-tcp-protocols] lists the supported TCP/IP standard features and Lambda extensions.

@figure
@setq figure-chaos-protocols figure-page
@sp 1
@settabs 3 @columns
@< @i[Feature] @\ @i[Description] @cr
@sp 1
@hrule
@sp 1
@< QFILE, LISPM-QFILE	@\ Transparent file access to remote hosts @cr
@< LOCAL-FILE		@\ Local host file access @cr
@< Mail			@\ Mail access to remote mail servers * @cr
@< Supdup		@\ Remote login @cr
@< Tiger		@\ Printing to local/remote Lambda hosts * @cr
@< Finger		@\ User login status @cr
@< Hostat		@\ Host ("are you there") status @cr
@< Extended Streams@tm@	@\ Inter-processor communications @cr
@<			@\ @ (streams and shared memory) * @cr
@< Disk			@\ Remote disk information @cr
@< Time			@\ Remote host time-of-day @cr
@cleartabs
@sp 1
@< * Non-MIT, Lambda extension @cr
@sp 1
@caption Chaosnet Family of Features and Functionality
@end(figure)


@fullpagefigure
@setq figure-tcp-protocols figure-page
@sp 1
@settabs 5 @columns
@< @i[Protocol] @\ @i[Description] @\ @\ @i[Use] @cr
@sp 1
@hrule
@sp 1
@< @b[Network Level:] @cr
@sp 1
@< IP @\ Internet Protocol @\			@\ (System internal use only) @cr
@sp 1
@< @b[Control/Transport Levels:] @cr
@sp 1
@< TCP	@\ Transmission Control Protocol @\	@\ Implementing complex protocols @cr
@< UDP	@\ User Datagram Protocol	@\	@\ Implementing simple protocols @cr
@< ARP	@\ Address Resolution Protocol	@\	@\ @ (System internal use only) @cr 
@< ICMP @\ Internet Control Message @\	@\ @ (System internal/diagnostic @cr
@<	@\ @ @ Protocol			@\	@\ @ @ use only) @cr
@sp 1
@< @b[Application Levels:] @cr
@sp 1
@< FTP	@\ File transfer protocol	@\	@\ Network-wide file access @cr
@< SMTP	@\ Simple Mail Transfer Protocol @\	@\ Mail access using ZMail @cr 
@< TELNET @\ Telnet Protocol		@\	@\ Remote login @cr
@< IMAGEN @\ Laser Printer Protocol	@\	@\ Printing to Imagen * @cr
@sp 1
@< @b[TCP and UDP Servers:] @cr
@sp 1
@< DISK @\ Remote Disk Protocol	@\	@\ Network disk functions @cr
@<	@\			@\	@\ @ (e.g. band transfers) @cr
@<	@\			@\	@\ @ between Lambdas * @cr
@< TIME @\ Host Time Protocol	@\	@\ Host time-of-day access * @cr
@< FINGER @\ TCP Finger Server	@\	@\ User login status * @cr
@< RWHO @\ Remote Who		@\	@\ User login status ** @cr
@< RUPTIME @\ Remote Uptime	@\	@\ System up-time status ** @cr
@sp 1
@< @starspace*Non-DOD, Lambda extension @cr
@< **Popular industry extension @cr
@cleartabs
@sp 1
@caption TCP/IP Family of Features and Functionality
@end(fullpagefigure)

@section Network Software Initializations

During the process of cold-booting, a Lambda runs various initialization functions
on the @l(cold) and @l(site) initialization lists to set up its networking environment.

Early in this process, the Lambda determines its own host identity.
It inspects the pack-name stored on the disk for its host name.
Host names are listed in the pack name in the order they appear on the system Nubus;
i.e, the slot 0 name is followed by the slot 4 name (if any), then the name of
the third LISP or Unix processor (if any).

@defun si:set-pack-name pack-name &optional unit
Set the pack name to the string PACK-NAME.
For example:

@lisp
(si:set-pack-name "lama lamb unix-a").
@end(lisp)
@end(defun)

@defun si:get-pack-name
Obtain the pack name from the disk; returns multiple
values, one for each name.
For example:
@lisp
(multiple-value-bind(slot0 slot4 unix)
    (si:get-pack-name)
   :
 )
@end(lisp)
@end(defun)

If the host's own name is listed in the loaded site information,
the host sets the variable @see[si:local-host][var] to its own host object,
along with other variables.
(See Section @ref[section-local-host-variables], @b(@nameref[section-local-host-variables])).

If the host's own host object is not defined, the host continues to initialize itself
in the same way, but it takes on the special host identity, ``@l(AMNESIA)''
(see Section @ref[section-amnesia], @b(@nameref[section-amnesia])).
When this host name appears during the booting process (and from @l(print-herald)),
it is a warning to the user that the proper site information must be loaded.
Local-file and remote access will probably not function properly until site files are loaded. 

When the network software is configured,
a tree of interfaces is established.
At the ``roots'' of the tree are the network interfaces (including the hardware drivers):

@itemize @bullet
@item ``ONE'' - 3COM or EXCELAN interface to the ETHERNET network
@item ``SHARE'' - interface to BACKPLANE network (inter-processor streams)
@item ``LOOPBACK'' interface to LOOPBACK network (used internally)
@end(itemize)

The network protocols establish access paths for the sub-protocols:

@itemize @bullet
@item ``INTERNET'' for TCP and UDP
@item ``CHAOS'' for Chaosnet
@item ``ARP'' for the Address Resolution Protocol
@end(itemize)

The Internet network protocol is broken down further into the IP gateway,
which in turn comprises the transport protocols and
assigned sockets through which the sub-protocols are implemented:

@itemize @bullet
@item ``TCP'' (TELNET, FTP, SMTP, DISK, TIME, FINGER)
@item ``UDP'' (RWHO, NAMESPACE, TIME)
@item ``ICMP''
@end(itemize)

TCP connections are established by the appropriate servers;
control connections come and go as required.

The current state of the interfaces, protocols, and connections are displayed by the @l(Peek)
program (see Section @ref[section-peek]).














@c end arch2