System 123 consists of System 122 with 10 patches and the New Network System (with TCP/IP) replacing the old network system. (System 122 was System 121 - the LMI development system, with all the patches that went into LMI Release 3.1. The intent was that it become Release 4.0; now, perhaps System 123 will be Release 4.0.) In System 123, the "System" system now includes the FANCY-LANDSCAPE subsystem (gauges) and excludes the COLOR and HACKS subsystems. The 123.0 band on the tape also doesn't have the Tiger system loaded into it. Any of these can be put in by the user with MAKE-SYSTEM. System 123 requires Microcode version 1754. In addition to various bug fixes, the big change (from the network viewpoint) is the %ip-checksum "misc" instruction, which speeds up IP/TCP considerably. Installation: The microcode and load bands are on the first tape (along with a dump of the SYS:NETWORK; directory tree as of the time I had just built System 123.) The second tape contains SYSDCL (system definition for SYSTEM, NETWORK, etc.) and 5 patches which I've made since creating the system. Patch 2 is essential to allow this system to properly talk Chaos to other processors on the backplane that are NOT running system 123 -- including Unix. With the patch, it SHOULD be compatible. I know it is for other Lambdas; let me know about Unix. Patch 4 is nice -- you can access the Imagen print options menu via the system menu. Patch 5 is necessary for the Site Editor. Patches 1 and 3 fix minor bugs. Some changes to your site files will probably be necessary as well. I suggest the use of the Site Editor 6.0, who's sources are on the first tape. With this system, Networks are named and defined in the site files. When you run the Site Editor, if no Networks are known, it will ask you to name one. You can then edit it and fill in the necessary fields. This is important -- the site editor will not allow you to assign an address that is not on a known network. System 123 also purports to support Internet Subnets. This is important for sites like MIT. You need to specify Subnet Masks in the site files; the site editor is set up to do that. If you don't specify subnet masks, IP assumes you are not using Internet Subnets. Any systems that intend to run System 123 and use TCP must be given an Internet address. Each processor on a backplane must be given a different Internet address, and Unix processors must be given NO Internet address. This is unlike the old TCP system, wherein all processors on the backplane were given the same Internet address. The old :default-internet-routing site option still exists and works exactly as before. A new site option, :broken-berkeley-broadcast-address-p is necessary 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 the site option to T, System 123 will also use this method, and will be able to broadcast to the Unix systems. If you set the site option to NIL (or omit it), System 123 will use the standard method of broadcasting, and will be able to talk to systems that properly use the standard (including later Berkeley Unix systems.) Configuration: System 123's network will work with a 3com, an Excelan, or with both. A system with a single board will configure itself such that the first processor to boot will control the board and the other processors will go through that processor. A system with two boards will give the 3com to the first, the Excelan to the second, and the other processors will go through the 3com owner. Note: I don't think that Unix knows enough to go through the Excelan owner if there is no 3com board. Useful functions and variables: (net:configure) is done automatically at cold or warm boot. It configures the system to use the (currently available) set of network boards & site info and starts the various network processes and protocols. If you change the configuration (choosing to reassign boards, for example), do this again. (net:deconfigure) is used to shut down network processing. Use of (chaos:reset) for this is obsolete and simply disables Chaos processing; IP/TCP is not affected. (si:set-processor-owning-ethernet &optional (operation :find) (board :all)) is the function to reassign boards. Operations can be :find, :take, or :give-up. Boards can be :3com, :excelan, or :all. This function should be called after a (net:deconfigure) and before a (net:configure). Two variables are useful in conjunction with this: si:dont-use-3com and si:dont-use-excelan force the appropriate board to be ignored (or relinquished) by si:set-processor-owning-ethernet. Note: if you reassign boards, or stop using a board, or start using a board after having stopped using it, you must perform a (net:configure) on ALL the systems on the backplane. Note: (net:configure) restarts all the network protocols. Due to the respective implementations, this causes all TCP and UDP connections to be reset, but does not cause Chaos connections to be reset. If this is seen as a big problem, it can be changed -- a simple matter of programming.... net:*network-protocols* is initially set to (:chaos :internet). This is the list of addressing domains / network protocols in the preferred order of use. Reverse the order to favor TCP over Chaos. Perhaps some more flexible mechanism could be devised; this is directly compatible with the previous TCP/IP implementation. Release 2.0 notes: Known Limitations and Restrictions: 3.1 FTP Command -- now exists. Try (ftp:ftp) 3.2 Network Access For Time -- well, we now have both a TCP Time Server and a TCP Time User. I don't know any reason they couldn't be used to get time from other TCP network hosts. I don't know what coding is required, but it can't possibly be too hard. 3.3 TCP Under UNIX -- still doesn't exist. 3.4 Compatibility With Foreign Hosts -- You should determine this. I would hope that we are compatible with all foreign hosts with all protocols... 3.5 Heavy Traffic -- will still slow down multiple processors. I have fixed the handling of the Share interface such that a 3x3 with just a 3com will treat both non-3com owners fairly, rather than always favoring one of them. 3.6 "EXOS reply" -- message doesn't exist anymore, of course. The likely equivalent is "TCP socket I/O". 3.7 Remote Login -- is now accessible in 4 ways: (tcp:telnet), Kermit Window, (kermit:telnet-h19), and (telnet:telnet-glass-tty). 3.8 TCP/IP and Chaosnet -- we still don't switch protocols if a connection fails. This means that you shouldn't give an Internet address to a host that is NOT running TCP/IP if you intend to favor TCP/IP over Chaos. 3.9 Printing Commands -- I have not touched Zmail; the "Move to Hardcopy" command presumably still won't use TCP. (hardcopy-file), ZMACS "Print Buffer", "Print File", "Print Region", Dired's "P" command, etc. all work nicely. 3.10 Processor Boot Order -- doesn't matter any more. Whoever boots first gets first choice of network interfaces; all other processors go happily through that processor. No need for a :front-end-tcp-chaos-server option in the site files nor for a surrogate call mechanism. Packages: In the old system, (practically) everything was in the TCP: package. I have defined many more packages for the new system: NETWORK: or NET: network related, not pertaining to specific hardware or network protocol. ETHERNET: 3com or Excelan ARP: Address Resolution Protocol CHAOS: Chaosnet INTERNET: or IP: Internet Protocol level stuff ICMP: Internet Control Message Protocol UDP: User Datagram Protocol TCP: Transmission Control Protocol TCP-APPLICATION: or TCPA: TCP or UDP applications without own package TELNET: Remote Login FTP: File Transfer SMTP: Mail Useful functions and Variables: (net:print-int-pkt-status) -- status of network packets (ethernet:exos-stats) -- statistics collected by Excelan board (arp:addr-stat) -- displays address translation cache (ip:list-route-table) -- displays known networks & Internet routing table (ip:add-gateway) -- Used to manipulate the IP routing table. This is (ip:remove-gateway) best done by manipulating :default-internet-routing site option (icmp:ping) -- Send an :echo or :timestamp request via ICMP User Manual: Everything said about FTP, Telnet, and SMTP should still be valid -- I ported all the old user and servers. Things added since, like (kermit:telnet-h19) still work. Chaos TCP Server still exists and should work. New applications: Unix compatible rwho/ruptime: use (tcpa:rwho) and (tcpa:ruptime) Band transfer: works over TCP via (si:copy-disk-partition) Finger: should work over TCP via (tcpa:finger-internet-host) Time: (tcpa:time-user-function) and (tcpa:time-user-function-udp) Imagen: (tcpa:set-imagen-print-options) which is also accessible from the system menu will set listing formats: 80 or 132 columns, 1 or 2 pages per page, optional page headings and/or line numbers. LISP support: The new system is mostly compatible with the old system. The Easy interface still exists and has been extended. TCP streams come in 3 flavors: tcp:tcp-buffered-stream, tcp:tcp-auto-buffered-stream, tcp:tcp-unbuffered-stream UDP streams also come in 3 flavors: udp:udp-stream, udp:udp-buffered-stream, udp:udp-unbuffered-stream To open a TCP stream specifying local and remote ports: (open "TCP-HOST:.#" ) To open a TCP stream specifying remote port: (open "TCP-HOST:." ) or (for compatibility): (open "TCP-HOST:#" ) To open a TCP stream specifying only local port (which implies LISTEN): (open "TCP-HOST:#" ) Valid keywords (and defaults) for any of these variants: (:keyword "Easy TCP stream") Name for PEEK (:connect t) T for active, NIL for passive (:buffered t) T for buffered, NIL for unbuffered (:auto-force-output nil) T if :string-out or :tyo forces a :force-output (:direction :both) or :input or :output (:input-buffers 4) Input buffers to keep out to TCP (:output-buffers 4) Output buffers available :coroutine-input Obsolete; for compatibility only. TCP streams no longer need backup process to be bidirectional. :for-udp Obsolete; for compatibility only. Use (open "UDP-HOST:...") :allow-other-keys... Any valid keyword for :open operation for a TCP-SOCKET All standard stream operations are available, plus a few special ones: :open is called by (open). You can call it directly following a (make-instance 'tcp:tcp-buffered-stream) if you want to specify special TCP options :remote-port to get the remote port number :remote-address to get the remote Internet Address :local-port to get the local port number :local-address to get the local Internet Address :accept to wait for a passive connection to complete. :close to close a connection :abort to abort a connection :listen to determine if data is available to read To open a UDP stream specifying local and remote ports: (open "UDP-HOST:.#" ) To open a UDP stream specifying remote port: (open "UDP-HOST:." ) or (for compatibility): (open "UDP-HOST:#" ) To open a UDP stream specifying only local port: (open "UDP-HOST:#" ) Valid keywords (and defaults) for any of these variants: (:keyword "Easy UDP stream") Name for PEEK (:raw t) T for raw UDP stream (:buffered t) If RAW is NIL, buffered or unbuffered (:receives-out 4) number of pending packets allowed :allow-other-keys... Any valid keyword for :open operation for a UDP-SOCKET All standard stream operations are available, plus a few special ones: :open is called by (open). You can call it directly following a (make-instance 'udp:udp-stream) if you want to specify special UDP options :remote-port to get the remote port number :remote-address to get the remote Internet Address :local-port to get the local port number :local-address to get the local Internet Address :close to close a connection :read-packet to get the next packet :write-packet to send a packet :broadcast-packet to broadcast a packet :bind to fully-specify a not-fully-specified connection :listen to determine if packets are available to read Generic Servers: (tcpa:define-network-service name protocol-name transport-protocol documentation &key toplevel-function listen-port auto-enable? stream-flavor) name is a variable that will be set to the structure describing this service. protocol-name is used for sockets displayed by PEEK. transport-protocol is :tcp or :udp documentation is for (documentation ' 'network-service) toplevel-function will be called with an open stream of specified flavor listen-port is port number or name to listen on auto-enable? is T if this server should be automatically started when you do a (net:configure) stream-flavor defaults to 'tcp:tcp-buffered-stream or 'udp:udp-stream. It can be any of the above documented stream flavors. (Need patch 123.7) (tcpa:disable-all-network-services) (tcpa:disable-one-network-service service) (tcpa:enable-all-network-services &optional also-do-non-auto-enable?) (tcpa:enable-one-network-service service) tcpa:*unwanted-connection-p* -- if not NIL, a function called with transport protocol (:TCP or :UDP) and socket (which supports :local-port, :remote-port, and :remote-address operations.) If it returns T then the connection will be aborted. tcpa:*tcp-generic-server-toplevel-debug* -- set to T to not catch errors Surrogate Function Call -- no longer exists. Socket Level Support: This no longer exists in a compatible way. TCP and UDP still have sockets, but the interface to them is completely different. The TCP and UDP stream flavors have been extended to provide all that was previously provided only by socket level calls. All existing Server and User applications have had socket-level calls removed and replaced with stream-level calls. Other Utilities: The Fancy Landscape system (performance gauges) is now part of System 123. Enable with (tv:fancy-landscape t) and disable with (tv:fancy-landscape nil) Excelan owners can use (ethernet:netspy) to look at all Ethernet packets. It will grab the Excelan board (with the knowledge of the network system) and give it back when it is done. Peek has a "Network Status" screen with many mouse-sensitive fields that can be used to look at many aspects of the network system. You can put up gauges in the control-panel for any network interface, network-protocol, transport-protocol, or TCP or UDP connection.