@library(patbo) @library(lisp) @tolerance 300 @overfullrule 0in @setpagewidth 6.25in @textbodyindent = 0.5in @begin(document) @baselineskip 13pt @parskip = 0.2in @parindent = 0in @secheadingskip .25in @defindex cp @defindex fn @synindex vr fn @synindex fl fn @synindex kw fn @setchapternewpage odd @headings off @settitle Release 4.0 Networking @setx titlecomment Release Notes (Preliminary) @setx lmipart Part XXXX-0000 (Rev 1) - @datestamp @headings off @titlepage @copyrightpage LMI LAMBDA, LAMBDA-PLUS, LAMBDA-2X2, and LAMBDA-2X2-PLUS are trademarks of GigaMos Systems, Inc. @sp 1 3COM is a trademark of 3COM, Inc. @sp 1 Excelan is a trademark of Excelan, Inc. @sp 1 Ethernet is a trademark of Xerox Corp. @sp 1 Unix is a trade mark of Bell Labs. @sp 1 TI-EXPLORER is a trademark of Texas Instruments @sp 1 SYMBOLICS is a trademark of Symbolics, Inc. @sp 2 Comments on this document and other documentation should be addressed to: @display GigaMos Systems, Inc. 650 Suffolk St. Lowell, MA 01854 Attn: Documentation @end(display) @end(copyrightpage) @headings on @evenheading @thispage@|@|@thistitle @oddheading @thistitle@|@|@thispage @chapter Introduction Release 4.0 LISP for GigaMos (formerly LMI) Lambda systems includes fundamental revisions to the Ethernet communications software products, TCP/IP and Chaosnet. This manual covers installation, configuration, operating procedures, and functional changes to the networking software. It accompanies the manual @i(4.0 LISP Release Notes); you should read that first, and install the 4.0 LISP software, before proceeding with the network configuration procedures documented here. The major changes are in the following areas: @itemize @bullet @item System/hardware architecture @item Installation procedures @item Site files / configuration information @item Operating procedures @item Miscellaneous features @end(itemize) Chapter @ref[chapter-architecture], @b[@nameref(chapter-architecture)], explains the most important changes and enhancements from the Ethernet software in Release 3. Subsequent chapters cover changes to system administration and software installation procedures. The final chapters cover specific changes to each sub-protocol. @sp 1 @textbox You (or the Lambda system manager at your site) @i(must) read this manual carefully, and perform the required site file modifications which are documented below, to use the release 4 networking software. @end(textbox) @chapter System / Hardware Architecture @label[chapter-architecture] The most significant changes from release 3 are to the low-level protocol drivers for both TCP/IP and Chaosnet. The relationship between the LISP processors and hardware interfaces has been radically altered; see @ref[figure-architecture] for a diagram of the functional relationships between components of the release 3 and release 4 communications architectures. @fullpagefigure @setq figure-architecture figure-page Compare the relationship between processors and hardware drivers, and the corresponding communications data-flow, in release 3 vs@. release 4. @vfill @end(fullpagefigure) In 4.0 LISP, every LISP processor on a Lambda system that is configured with at least one Ethernet Communications Interface board, either a 3COM or Excelan, can use both protocols. In previous releases, each protocol was implemented with a different hardware interface -- 3COM for Chaosnet, Excelan for TCP/IP. On Lambda systems with multiple LISP processors, the first processor to boot (usually the slot 0 processor) allocated the Ethernet board(s) and served as the front-end for other processors on the bus. Given a heavy load of network traffic, this could result in unacceptable performance degradation. With release 4, a Lambda processor needs access to only one board to support both TCP and Chaosnet. The system can support up to two boards (of either type), one for each of two processors. For example, on a Lambda-2x2 with one 3COM and one Excelan, slot 0 will allocate one, and slot 4 will use the other. The boot order is not important, but for consistency, the first processor to boot will allocate a 3COM (if present), the second will allocate the Excelan (if present); a third Lambda (on a 3x3) will, by preference, go through the 3COM owner. All Lambdas on the bus can share one board, if only one is available. When the LISP processor(s) boot up, a system with a single board will configure itself such that the first processor to boot will control the board and the other LISP processor(s) will go through the first processor, using the Extended Streams Interface@tm@ to access the network. This significant rewrite of the low-level communications support should result in improvements over release 3 even in systems with a single hardware interface. There are no new restrictions on networking imposed by the new architecture, and no hardware modifications are required. Note that Lambda-Plus Unix System 5 software does not support the Excelan interface. Unix still goes through a LISP processor for Chaosnet network access, and does not itself provide any TCP/IP access. As before, however, the Unix utility 'cftp' can be used to issue file transfer requests to a Chaosnet host, specifying a pathname to a remote TCP host. @chapter Installation Procedure @label[chapter-installation] The networking software in 4.0 LISP is loaded in the band and does not require any installation, enabling, or decryption procedure. The sources {are not / are?} provided with the LISP 4.0 distribution. See the @i(4.0 LISP Release Notes) for information on installing 4.0 LISP software. Otherwise, in general, the information in the manual @i(Release 3.0 TCP/IP Installation and Release Notes) is still valid, and that manual is still the current primary reference for TCP/IP. But be sure to read Chapter @ref[chapter-operating], @b[@nameref(chapter-operating)], for detailed information on function names, arguments, etc. @chapter Configuration Procedures @label[chapter-config] Some changes to the Lambda site configuration information -- hereafter referred to as @i(site files) -- may be required for the new release. Changes are definitely required in a TCP/IP network. These changes may not be downward-compatible; in other words, site files modified for 4.0 networking software should not be used or loaded in a 3.0 LISP world. See below for information on modifying network addresses for release 4. Most Chaosnet-only installations will not require updated site files. However, we recommend recompiling and reloading the site files anyway. Also, sites that were previously Chaos-only may wish to take advantage of the TCP/IP capability that comes with release 4. @section Site Configuration Changes The site file changes documented below are all changes to entries in the files contained in the directory with the logical pathname @ii(SYS:SITE;). These files are: @itemize @bullet @item SYS.TRANSLATIONS @item HOSTS.TEXT @item SITE.LISP @item LMLOCS.LISP @end(itemize) @subsection Logical Translations There is one change you will have to make to your working @ii(SYS.TRANSLATIONS) file. Release 2 sources were located in the @ii(QL;) directory; release 3 sources were located in the @ii(RELEASE-3;) directory; and release 4 sources are located in the @ii(RELEASE-4;) directory. You must modify your working version of @ii(SYS.TRANSLATIONS) to reflect this change. The distribution template file @ii(SYS.TRANSLATIONS), which is in the directory @ii(RELEASE-4.CUSTOMER-SITE;) on the LISP options tape, illustrates the required syntax. If you move your site files to a new directory (as recommended), you will also have to modify the definitions of @ii(SYS:SITE;) and @ii(SYS:CHAOS;) to reflect the new location of your site files. See @ref[figure-sys-translations] for an example of a release 3 and modified release 4 @ii(SYS.TRANSLATIONS) file. @figure @setq figure-sys-translations figure-page @i(Release 3 example of) SYS.TRANSLATIONS: @example ;;; -*- Mode:LISP; Base:10; Readtable:ZL -*- (FS:SET-LOGICAL-PATHNAME-HOST "SYS" :PHYSICAL-HOST "MASTER-HOST" :TRANSLATIONS '(("CHAOS;" "RELEASE-3.CUSTOMER-SITE;") ("SITE;" "RELEASE-3.CUSTOMER-SITE;") ("*.*.*.*.*;" "") ("*.*.*.*;" "") ("*.*.*;" "") ("*.*;" "") ("*;" ""))) @end(example) @i(Release 4 example of) SYS.TRANSLATIONS: @example ;;; -*- Mode:LISP; Base:10; Readtable:ZL -*- (FS:SET-LOGICAL-PATHNAME-HOST "SYS" :PHYSICAL-HOST "MASTER-HOST" :TRANSLATIONS ;;Copied site file directory to "MASTER-HOST:OUR-SITE4;" '(("CHAOS;" "OUR-SITE4;") ("SITE;" "OUR-SITE4;") ("*.*.*.*.*;" "") ("*.*.*.*;" "") ("*.*.*;" "") ("*.*;" "") ("*;" ""))) @end(example) @caption Examples: original and modified (release 4) SYS.TRANSLATIONS file @end(figure) @subsection Host Addresses In previous releases, all hosts within one Lambda chassis were assigned the same Internet address. You must modify your 4.0 site files (in @ii(HOSTS.TEXT)) as follows: @itemize @bullet @item Each Lambda LISP host must have its @i(own) Internet address @item Lambda-Plus Unix hosts must have @i(no) Internet address @end(itemize) Chaos addresses for all Lambda hosts are still required; they are always used for interprocessor communication within the same chassis. See @ref[figure-hosts-text] for an example of a modified @ii(HOSTS.]TEXT) file. @fullpagefigure @setq figure-hosts-text figure-page @i[Release 3 example of] HOSTS.TEXT: @example ;;; -*- Mode:Fundamental -*- HOSTS2 TABLE MASTER: RELEASE-3.CUSTOMER-SITE; HOSTS.TEXT#18 HOST LMI-AMNESIA, CHAOS 3412,USER,LISPM,LISPM,[AMNESIA] ;; Lambda 2x2-Plus HOST MASTER-HOST, [CHAOS 3430,INTERNET 101.0.0.101],USER,LISPM,LISPM,[MASTER] HOST NOTHER-HOST, [CHAOS 3431,INTERNET 101.0.0.101],USER,LISPM,LISPM,[NOTHER] HOST MYUNIX-HOST, [CHAOS 3432,INTERNET 101.0.0.101],USER,UNIX,NU,[MYUNIX] ;;; Lambda HOST XTRA-HOST, CHAOS 3433,USER,LISPM,LISPM,[XTRA] ;; VMS VAX HOST VMSVAX-HOST, INTERNET 101.0.0.110,USER,VMS,VAX,[MYVAX] @end(example) @i[Release 4 modified example of] HOSTS.TEXT: @lisp ;;; -*- Mode:Fundamental -*- HOSTS2 TABLE MASTER: OUR-SITE4; HOSTS.TEXT#20 HOST LMI-AMNESIA, CHAOS 3412,USER,LISPM,LISPM,[AMNESIA] ;; Lambda 2x2-Plus HOST MASTER-HOST, [CHAOS 3430,INTERNET 101.0.0.101],USER,LISPM,LISPM,[MASTER] HOST NOTHER-HOST, [CHAOS 3431,INTERNET 101.0.0.102],USER,LISPM,LISPM,[NOTHER] HOST MYUNIX-HOST, CHAOS 3432,USER,UNIX,NU,[MYUNIX] ;;; Lambda HOST XTRA-HOST, [CHAOS 3433,INTERNET 101.0.0.103],USER,LISPM,LISPM,[XTRA] ;; VMS VAX HOST VMSVAX-HOST, INTERNET 101.0.0.110,USER,VMS,VAX,[MYVAX] @end(lisp) @caption Examples: original and modified (release 4) SYS.TRANSLATIONS file @end(fullpagefigure) @subsection Site Options Added and Removed A few site options need to be added or removed. Site options are specified globally, for all Lambdas using the site files, in @ii(SITE.LISP), or locally, for specific Lambdas, in @ii(LMLOCS.LISP). The site option changes for release 4 are as follows: @description @item :BROKEN-BERKELEY-BROADCAST-ADDRESS-P @i([T or NIL]) This site option must be specified if there are Berkeley Unix 4.2 systems on your network. Such systems have a non-standard method of doing IP broadcasting. If you set this option to @i(T) (true), release 4 TCP/IP will also use this method, and will be able to broadcast to the Unix systems. If you set the option to NIL (or omit it), release 4 will use the standard method, and will be able to broadcast to systems that properly use the standard method (including systems running later Berkeley Unix releases, as updates become available). To enable Berkeley 4.2 IP broadcasting compatibility, add the following line within the @l(DEFSITE) in the file @ii(SITE.LISP): @lisp (:broken-berkeley-broadcast-address-p T) @end lisp @sp 1 @item :FRONT-END-TCP-CHAOS-SERVER This option is no longer needed, and it is not supported by release 4. Chaos-only Lambda hosts that formerly had to go through a remote front-end TCP/Chaos server can, and must, be updated to use release 4 TCP/IP software directly. Delete any lines in @ii(SYS:SITE;SITE.LISP) or @ii(LMLOCS.LISP) that specified the :FRONT-END-TCP-CHAOS-SERVER option. Note that this will make the new site information incompatible with release 3; loading the new site files in a release 3 band would eliminate the front-end TCP-Chaos serving capability. @end(description) @section Preparing Release 4 Site Files Following is a procedure for preparing site files for use with release 4. All of the procedures in this section should be performed on the @b(sys host); this is normally the file-server host on which system files, site files, etc. have been stored. You must first establish the location of the "old," or template, site files (either your 3.0 site files, or the sample files provided by GigaMos). Then you can prepare new site files and save a band with site information. @subsection Using the Sample Site Files If you are installing 4.0 software on your first Lambda system, and you haven't previously loaded 3.0 site information, you will need to start with the sample set of site files provided by Gigamos. Follow the procedure for restoring the sample site files provided in the @i(4.0 LISP Release Notes). Then, @i(working on the sys host), you can establish the logical host directory pathname @ii(SYS:SITE;) by executing @lisp (si:set-sys-host "lm" nil nil "release-4.customer-site;") @end lisp Proceed to the step below, @b(@nameref[section-verify-site-files]). @subsection Using Previously Established Site Files If the site files you have modified and loaded in the past are located on the @b(local machine) (the one you are working on), you can execute the following to point to @ii(SYS:SITE;) as the site file directory: @lisp (si:set-sys-host "lm" nil nil "") @end lisp ...where you substitute the actual directory name where the site files are located in place of @i(). If the site files are located on another Lambda Chaosnet host, you can point to them remotely. For example, assume there is a host @b(MASTER-HOST) with Chaos address (octal) 3430. It contains site files in the directory @ii(OUR-SITE;) which were used with release 3. You would execute the following to point to these site files: @lisp (si:set-sys-host "master-host" :lispm #o3430 "our-site;") @end lisp @subsection Verify Access to Site Files @label[section-verify-site-files] Once you have a set of working or template site files, you should verify that you can access them: @lisp (listf "sys:site;") @end lisp @subsection Copying Site Files to a New Directory Now you should copy the working or template site files to a new directory which will be specifically for release 4 site files. Select a directory name which will indicate its purpose. If, for example, you want to establish the top-level directory @ii(OUR-SITE4;) you would execute the following (make sure you are working on the @b[sys host]): @lisp ;;To copy the site files: (fs:copy-directory "sys:site;*.*#>" "lm:our-site4;") ;;To point to the new site file directory: (si:set-sys-host "lm" nil nil "our-site4;") ;;To verify that you can access the new directory: (listf "sys:site;") @end lisp Finally, you are ready to make the changes for release 4 that were described above. @section Edit Site Files The most direct way to make changes to your site files is to edit the files directly with ZMacs. You can bring up a directory listing by executing @lisp (dired "sys:site;*.*#>") @end lisp To edit a particular file, position the cursor on the file name and press '@i(E)'. Make your changes in each file as described in the previous section. Be sure to save each file with @ctrl(X) @ctrl(S). @figure Make sure you make the following changes in @ii(HOSTS.TEXT): @itemize @bullet @item Give each LISP processor its own Chaos and Internet addresses @item Remove (or don't add) the Internet address for Lambda-Plus Unix hosts @end itemize Make sure you make the following changes in @ii(SITE.LISP) and/or @ii(LMLOCS.LISP): @itemize @bullet @item Add the following line to @ii(SITE.LISP) if you have Berkeley Unix 4.2 systems on the Internet: @lisp (:broken-berkeley-broadcast-p t) @end(lisp) @item Remove the :FRONT-END-TCP-CHAOS-SERVER option wherever it appears @end(itemize) Make sure you make the following changes in @ii(SYS.TRANSLATIONS) : @itemize @bullet @item Specify @ii(RELEASE-4;) as the translation for sources @item Specify your own site directory as the translation for @ii(SYS:SITE;) and @ii(SYS:CHAOS;) @end itemize @sp 1 @caption Site File Modification Check-List @end(figure) @section Recompile Site Files After editing and saving the files, they must be (re)compiled. To recompile all the files and load and test the changes, execute: @lisp ;;Recompile site files: (make-system 'site :compile :noload :noconfirm :no-reload-system-declaration) ;;Load new site files: (update-site-configuration-info) ;;Make sure SYS.TRANSLATIONS points to the right site files! (listf "sys:site;") : : ;;Reload new site information: (update-site-configuration-info) NIL ;;This should hear back from all available Chaos hosts: (hostat) Site Name/Status Subnet ... 3701 Our Lambda ... : : ;;Use a remote TCP host name - asks for an echo (icmp:ping 'my-vax) 6 NIL @end lisp If you make further changes in just one file, or a few files, you can recompile just the modified files by executing: @lisp (make-system 'site :compile :noload :noconfirm :no-reload-system-declaration) @end lisp @section Update Site Configuration Info To load the site files you have just recompiled, execute @lisp (update-site-configuration-info) @end(lisp) This is the end of the edit / compile / load cycle for the site files. Remember: every time you change one of the site files, you must execute a form of @l[(make-system 'site)]. And every time you run @l[(make-system 'site)] you must do this to properly load the site information. @section Save a Band with Site Information @chapter Operating Procedures @label[chapter-operating] This chapter details changes to functions and variables that are part of the networking software. The functions include general system management and operating procedures. Protocol-specific changes are discussed in Chapter @ref[chapter-applications], @b[@nameref(chapter-applications)], below. @section Functions @defun net:configure @defunx net:deconfigure Start up (@l(configure)) or shut down (@l(deconfigure)) network processes and protocols. @l[configure] tells the local processor to use the currently available set of network boards and site information. Both reset TCP and UDP connections, but not Chaos connections. @end defun Note that use of @l[(chaos:reset)] for resetting Chaosnet is obsolete but still available. The @l(TCP:) analogues, @l[(start)] and @l[(tcp-disable)], are no longer implemented. @defun si:set-processor-owning-ethernet &optional (operation :find) (board :all) Change the processor controlling the ethernet boards.@* If there is no ethernet board, make sure this machine knows not to use it.@* If the argument is :FIND (the default) figure out who owns the board so we can send packets to him. If no one currently owns it, we allocate it.@* If the argument is :TAKE or T, then steal it from the owner.@* If the argument is :GIVE-UP or NIL, then deallocate it so someone else can have it. This function should be called after deconfiguring and before reconfiguring, as follows: @lisp (net:deconfigure) (si:set-processor-owning-ethernet ...) (net:configure) @end(lisp) If you reassign boards you must perform a @l[(net:configure)] on @i(all) the processors in the chassis. @end(defun) @defun ftp:ftp &optional remote-hostname The File Transfer Protocol command. Optionally connects to specified @l(REMOTE-HOSTNAME). Previously implemented as @l(ftp:cmd). @end(defun) See @see[ftp:ftp][fun] for details. @c section @ref[section-ftp], page @pageref[section-ftp] below, @defun icmp:ping host &optional (operation :echo) (data nil) Do an ICMP Echo, Timestamp, Information Request, or Address Mask. This function passes the specified Internet host an ICMP request corresponding to @l(OPERATION), passing @l(DATA) if specified. Valid @l(OPERATION) arguments are @l(:ECHO), @l(:INFO), @l(:ADDRESS-MASK), and @l(:TIMESTAMP). @l(PING) returns two values. The first is NIL for no answer, or the lag-time in clock-ticks (1/60'th second) if an answer was received. The second value (often NIL) is data received from the remote host. @end(defun) @defun net:print-int-pkt-status &optional print-all Print status of packets to be handled at microcode interrupt level. A fixed array of packet buffers is configured by the system. Each packet buffer is either free for use by some protocol, waiting to be tramitted, or just received. With no argument, @l(PRINT-INT-PKT-STATUS) lists the number of free, transmit, and receive packets; if @l(PRINT-ALL) is non-NIL, the function displays, for each packet buffer, its associated protocol and status. @end(defun) @defun ethernet:exos-stats &key reset-p Print Exos statistics collected by hardware interface. Unfortunately, only the Excelan board supports this feature. Non-NIL @l(RESET-P) resets the collected statistics. @end(defun) @defun ethernet:netspy Look at all ethernet packets seen by the Excelan board. For documentation, execute @l[(documentation 'ethernet:netspy)]. @end(defun) @section Variables There is one parameter variable that was not previously documented, and a status variable that has been removed. @defvar net:*network-protocols* (:CHAOS :INTERNET) This is the list of keywords that correspond to addressing domains and network protocols in the preferred order of usage. By default, the system will "prefer" Chaosnet access over TCP/IP. @end(defvar) For example, remote hosts accessible by both Chaosnet and Internet file access methods will by default be accessed through Chaosnet for file transfer. (This is preferable for file access between Lambdas, since Chaosnet provides LISPM-specific information that TCP/FTP cannot provide.) By reversing @l(*network-protocols*), TCP/FTP would be favored. In general this variable should not be manipulated; under special circumstances, however, one could force TCP access in a limited situation by binding the variable.@* @i[and resetting file access]@* @b[but I still can't get this to work!???] The variable @l[tcp:dma-initialized-p] is no longer present. Formerly, this variable had to be @l(SETQ)'ed to reinitialize the Excelan board. This is no longer necessary.@* @b[??? When, exactly, is it init'd now? configure???] @chapter Miscellaneous Features / Applications @label(chapter-applications) @section FTP @label[section-ftp] The most significant changes to the File Transfer Protocol are internal and not visible to the user. The command interface to FTP, formerly called @l(ftp:cmd), is now defined as @l(ftp:ftp). Various options have been modified and improved, and the interface is more robust. @defun ftp:ftp &optional remote-hostname The File Transfer Protocol command. Optionally connects to specified @l(REMOTE-HOSTNAME). @end(defun) This command interface is what other TCP/IP implementations provide in place of the "transparent" access provided by the Lambda software. It is useful on the Lambda if, for example, the normal Lambda file access functions (@l[dired], @l[copy-file], @l[directory], etc.) are not working because of pathname parsing problems. Pathnames are passed without translation from @l(ftp:ftp) to the remote FTP server. Type @i(?) to see the help on each command. In the help listing, optional arguments are enclosed in brackets, after any required arguments. If a command is entered without arguments, the user is prompted for every one; enter @return to skip options. The most commonly used commands include: @itemize @bullet @item @i(? [command]) - list help information on all commands or a specific @i(command)) @item @i(OPEN [to]) [username] [password] - open a connection to a remote host. @item @i(DIR remote-directory [local-file]) - list directory contents of @i(remote-directory); optionally, save listing in @i(local-file). @item @i(PWD) - print working directory on remote host. @item @i(CD remote-directory) - change remote working directory to @i(remote-directory). @item @i(STATUS) - show current status of environment commands. @item @i(USER [username] [password] [account]) - login and send new user information. @item @i(SEND local-file [remote-file]) - transfer @i(local-file) from local system to @i(remote-file) on remote system. @item @i(GET remote-file [local-file]) - transfer @i(remote-file) from remote system to local system as @i(local-file). @item @i(CLOSE) - terminate FTP session. @item @i(QUIT) - terminate FTP session and exit. @end(itemize) @section Telnet @label[section-telnet] There are now four different ways to access the Telnet program from LISP. The Kermit interfaces provide H19 terminal emulation, which is supported by many other Telnet servers. The basic Telnet and "glass tty" interfaces provides only the most basic "dumb terminal" kind of terminal I/O. The primary Telnet interface in LISP is through the Kermit program. Within @b(Review Parameters), the user selects @t(TCP Telnet) to specify Telnet for future connections. The @b(Connect) command is then used to initiate an H19 emulating terminal window to the remote host's Telnet server. Use the keystroke @neton[K] to disconnect after logging out.@* @b???test-VAX flaky, 'connection refused' most of the time @defun kermit:telnet-h19 &optional to-host Connect to @l(TO-HOST). Substantially the same as the Kermit window interface. @end(defun) @defun tcp:telnet host Open a Telnet connection to the remote @l(HOST) with no special terminal emulation. @end(defun) @defun telnet:telnet-glass-tty address &optional (port "TELNET") (HALF-DUPLEX NIL) This glass TTY works well enough for testing purposes. The argument, @l(ADDRESS), is specified as a string containing the TCP/IP network address; for example, "101.0.0.10". This function was formerly in the @l(TCP-APPLICATION:) package. @end(defun) The @l(TELNET-GLASS-TTY) interface is crude, but the arguments it takes provide two advantages over the other TELNET functions for debugging purposes. Using the @l(ADDRESS) argument effectively bypasses the site file information (or lack thereof) regarding a particular host. Also, you can test the ability to connect to specific TCP services on a remote host. For example, to test if a remote host provides SMTP, you could execute the following (specify the correct address): @lisp (telnet:telnet-glass-tty "101.0.0.10" "SMTP") @end(lisp) @section SMTP Good luck! @appendix Networking Software - LISP Packages @label[appendix-packages] In previous releases of TCP/IP, almost all symbols were in the @l(TCP) package. In release 4, many symbols have been moved into new or pre-existing packages. For example, generic network functions have been grouped together in the @l(NETWORK) package. Here is a summary of the LISP packages created and used by networking software: @sp 1 @settabs 2 @columns @< @i[Package (Alias)] @\ @i(Description) @cr @sp 1 @< NETWORK: (NET:) @\ Generic (not protocol-specific) network interfaces @cr @sp 1 @< ETHERNET: @\ Hardware drivers (3COM or Excelan) @cr @sp 1 @< ARP: @\ Address Resolution Protocol @cr @sp 1 @< CHAOS: @\ Chaosnet protocol @cr @sp 1 @< INTERNET: (IP:) @\ Internet Protocol @cr @sp 1 @< ICMP: @\ Internet Control Message Protocol @cr @sp 1 @< UDP: @\ User Datagram Protocol @cr @sp 1 @< TCP: @\ Transmission Control Protocol @cr @sp 1 @< TELNET: @\ Remote Login application @cr @sp 1 @< FTP: @\ File Transfer Protocol @cr @sp 1 @< SMTP: @\ Simple Mail Transfer Protocol @cr @sp 1 @< TCP-APPLICATION: (TCPA:) @\ Other TCP or UDP applications @cr @cleartabs @unnumbered Index @printindex cp @printindex fn @contents @end(document)