What the old TCP system provides: TCP/UDP/IP/ICMP on the Excelan card, providing one Internet Address per card cage. Thus, only one processor can have servers running. One processor per card cage owns the Excelan board, other Lambda processors that need TCP send packets through that processor. FTP, Telnet, SMTP, Band transfer, Finger server programs. FTP, Telnet, SMTP, Band transfer, Finger, Time and Imagen user programs. Programming interface: raw socket-level: make-socket-address, open-socket, close-socket, socket-accept, socket-connect, udp-socket-read udp-socket-write "Easy" support: (open "TCP-HOST:
#") returns: TCP stream (character): buffered, unbuffered, auto-push Provide :tyi, :tyo, :string-out, :force-output, :listen. etc. UDP stream (datagrams): buffered, (unbuffered?) Provide :read-packet, :write-packet, :listen, and :close Generic server -- system processes "listens" for connections and passes open stream to process running user supplied function. Unix support: none. Lambdas can communicate with Unix via Chaos over backplane. Unix passes Chaos packets to network through the Lambda that owns the 3com. :default-internet-routing site option specifies available gateways What the initial offering of the new TCP system will provide: TCP/UDP/IP/ICMP in Lisp runnning on each Lambda. Each processor has its own Internet address. Thus, any server can be run on all machines. All TCP and IP options are available. Internet Subnets are supported. Either a 3com or Excelan card may be used to communicate with the network; If both are present, one processor will take one, the other processor will take the other. If only one card is present, one processor will take it and the other processors will send TCP and Chaos packets through that processor. FTP, Telnet, SMTP, Band transfer, Finger, Time, Rwho server programs. Ftp, Telnet, SMTP, Band transfer, Finger, Time, Rwho, Imagen user programs. Peek screen for "Network Status" Gauges for any network entity: network interface, network protocol, TCP connection or UDP connection. Programming interface: "tcp-socket", "udp-socket", and "icmp-socket" give you complete control of your TCP or UDP connection, but are at a lower level than a normal stream and thus require more work to use. Almost no programs should need to use this level of interface; all features that previously required socket-level programming are now available at the stream-level. "tcp-stream": a standard bidirectional stream. Can be configured to be input-only or output-only. Is layered on top of the "tcp-socket" and hides the details of interacting with it. Layered on top of this are "tcp-buffered-stream", "tcp-unbuffered-stream", and "tcp-auto-buffered-stream". "udp-stream": a stream that supports :read-packet, :write-packet, :listen, and :close that is layered on top of "udp-socket". Layered on top of this are "udp-buffered-stream" and "udp-unbuffered-stream". "Easy" interface -- allows you to open TCP or UDP connections by using the TCP-HOST: or UDP-HOST: pseudo-devices Generic server -- a single system process "listens" for TCP and UDP connections and passes a standard buffered stream to user supplied function when connection opens. [There are several things documented in the TCP/IP User Manual, Release 2.0 as "Other Utilities" that are no longer used internally by the network system: Surrogate function calls, Coroutine streams, EVAL-HOST, tcp:transmit-raw-ethernet-packet. Do we need to continue to provide them?] Unix support: none. Lambdas can communicate with Unix via Chaos over backplane. Unix passes Chaos packets to network through the Lambda that owns the 3com. :network-names site option specifies networks, numbers, subnet masks :default-internet-routing site option specifies available gateways :broken-berkeley-unix-broadcast-address-p site option Things that need to be done to bring my network system up to this level: Configuration, Site Files, Device Drivers: (0 days) Done. IP: (0 days) Done. ICMP: (0 days) Done. TCP: (0 days) Done. UDP: (0 days) Done. TCP stream, UDP stream, Easy interface, Generic Server: (0 days) Done. User & Server FTP: (0 days) Done. User & Server Telnet: (0 days) Done. User & Server SMTP: (0 days) Done. User & Server Band: (0 days) Done. User & Server Time: (0 days) Done. User & Server Rwho: (0 days) Done. User Imagen: (0 days) Done. Fold into existing sources and build new cold load. (0 days) Done. Compatibility Functions: (?? days) Surrogate, coroutine streams, etc. I hope we can ignore this. Otherwise, prepare a file with all the old code in it. Test, test, test: (?? days) The lower level stuff seems solid. User level stuff needs testing. Ideally, the system should be installed on a variety of Lambdas and 2 by 2's (some with one network interface, some with two) and beaten on. I'd be interested in seeing how it works on a 3 by 3. Test how it works with unmodified LMI Unix. Test how it works on networks with real gateways. Deficiencies: Configuration There are some issues involving systems with more than one network interface (i.e. a 3com AND an Excelan.) Currently, first processor takes 3com, second takes Excelan, third gets none. Processors without a network interface go through 3com owner (or Excelan, if no 3com). If a processor owning an interface dies, nobody takes the board. Share device buffers are currently (1024 - ) bytes long. TCP/IP will make full use of whatever is available, up to the size of an INT-PKT. The share buffers should handle a full ethernet packet (1500 bytes). They should be double-buffered. The Share Device protocol for communicating between processors over the backplane has been modified to include the protocol type in the upper half of the "length" word. Chaos is defined as "0", so communications with unmodified LMI Unix SHOULD work, but this has not been tested -- and Unix should be fixed to look at the protocol type and discard the packet unless it is Chaos. IP No special support for IP Self-Address packets. Really can't have until Berkeley Unix 4.2 disappears, as it (erroneously) uses the Self-Address as the Broadcast Address. ICMP Perhaps Destination Unreachable messages should update route table? Remove a gateway that is declared to be unreachable... Parameter Problem messages increment a statistic, but should be stored (and notification given) when they arrive, as they indicate that some gateway thinks we have a bug in our IP! Information Request and Information Reply messages not supported. Not a big deal -- they are an obsolete mechanism for a host to find out its network number if it knows its host number. TCP Should handle ICMP Source Quench message by backing off on packet transmission for the connection that prompted the ICMP message. Currently just passes the Source Quench up to user -- who has no control over TCP's rate of transmission! Dave Clark's RFC on Silly Window Syndrome describes an algorithm for the Receiver to use to avoid SWS that involves delaying ACKs and sending them when receive window opens up "enough". We have a different delayed ACK strategy based strictly on timing that seems to work quite well, but we might want to add in or use the published algorithm -- perhaps it has better performance? "It is a bad idea to delay an ACK more than 1/2 median inter-packet- arrival-time." We don't measure that. Nor do we adaptively modify our ACK delay, other than to turn it off altogether if it is not doing any good for a particular connection. Research... TCP-STREAM Urgent data indication and ICMP messages are ignored. UDP-STREAM ICMP messages are ignored. Possible future network projects: A Lambda could act as a gateway between two Ethernets. Site files describe available networks and gateways Configuration code to match network interfaces and network addresses Chaosnet code already exists to forward packets and deal with Chaos routing protocol. IP code already exists to forward and fragment packets. A standard IP routing protocol (EGP) is needed. Serial line, modems, point-to-point links. A link-layer protocol for running IP over serial lines already exists and is implemented at MIT -- you can dial up a "Serial Line IP (SLIP)" machine. Given this, we'd have remote login, mail, file transfer, etc. over dialup. We could set up remote access for bug reports, patch distribution, and other customer support functions. TFTP (Trivial File Transfer Protocol) over UDP. Domain Name Server and Resolver arpanet style host names: pld@angel.lmi.com This is present in mail system, but need a real domain name resolver. Protocol standards exist and are implemented. Built on top of UDP or TCP. Sun Network File System XDR, RPC, NFS over UDP. GJC has an implementation over old system. Need a better Terminal Emulator, Telnet user Interface, etc. None of the Telnet interfaces actually do proper option negotiation. SUPDUP over TCP? (The protocol exists and has standard TCP port...) Other Chaos Protocols over TCP? SUPDUP, QFILE, NFILE .... I hear that Pace did much work on a SUPDUP server. Imagen support Port James Turner's multiple-font Imagen support to the new TCP.