Network Working Group David Walden
Request for Comments #365 Bolt Beranek and Newman Inc.
NIC # 10607 July 11, 1972
Categories:
Updates:
Obsoletes:
A LETTER TO ALL TIP USERS
Dear TIP Users,
You will shortly be sent a revised version of the "TIP User's
Guide." Besides now having a loose leaf format, mainly descriptions
of new commands have been added. Appendix B will be an alphabetical
list of all TIP commands. The new commands are:
@BINARY INPUT START
@BINARY INPUT END
@BINARY OUTPUT START
@BINARY OUTPUT END
@CLEAR DEVICE WILD
@CLEAR INSERT LINEFEED
@INSERT LINEFEED
@SEND COMMAND
@RECEIVE FROM WILD
@SEND TO WILD
@SET DEVICE WILD
@MAG ABORT
@MAG BACKSPACE FILE
@MAG BACKSPACE RECORD
@MAG READ FILE
@MAG READ RECORD
@MAG SETUP COPY
@MAG SPACE FILE
@MAG SPACE RECORD
@MAG UNLOAD
@MAG WRITE EOF
@MAG WRITE TAPE
The MAG commands are, of course, not relevant to users of TIPs without
the magnetic tape option.
A TIP system including the above commands has been in operation
since late June. We think this system is a substantial improvement
over previous versions.
[Page 1]
RFC # 365 July 11, 1972 In case you've not been keeping track, there are now eleven TIPs in the ARPA Network. These are ETAC, GWC, AMES, ARPA, MITRE, NBS, BBN, USC, NOAA, ROME, and SAAC. Also, a TIP will soon be installed at CCA. I'll now briefly discuss a number of topics I think may be interesting to you. Getting TIP status information. As we develop new features for the TIP and fix bugs, we are continually releasing new versions of the TIP program. We do this by just reloading your TIP when you're not looking (i.e., when no one is using your TIP). In the future we will notify you whenever a new version of the TIP program is loaded into your TIP by adding a tiny "status message" to the "HELLO" you get when you "log onto" the TIP. This status message will usually be merely the TIP's version number; however, occasionally the message will indicate (by typing "NEWS") that there is some news about the TIP's status which you should read before continuing your session with the TIP. The NEWS can be retrieved by typing the command @NEWS which will ICP to a special socket at BBN's TENEX or PDP-1D which will print the news. Of course, either of these systems may sometimes be down, but we won't worry about the problem until we see how serious it is. To whom to complain or make suggestions. Many of you have had occasion to complain about the operation of your TIP system or to make suggestions for its improvement. All too frequently, however, these complaints have been directed to the Host system you are using from the TIP instead of to us. BBN maintains a Network Control Center which is always manned. Its telephone number is 617-661-0100. All TIP problems should be reported immediately to the Network Control Center. If you have a suggestion for a new command, or if you think you've found a subtle bug in the TIP program, ask to talk to Dave Walden or Bernie Cosell when you call the Network Control Center. Device buffers. In general, each TIP MLC port has a different size buffer allocated to it and therefore to the device connected to the port. Devices which operate at higher speeds, of course, require larger buffers, especially output buffers. If you need more buffering than you have (frequently indicated by output coming in short bursts), try to arrange with whomever is locally responsible for the TIP you're using to come in through a port with a larger buffer allocation. If necessary, this person can arrange with us to specially tailor the buffer allocation for your TIP. [Page 2]
RFC # 365 July 11, 1972 There are presently only about 2500 characters of buffers available for the TIPs terminal devices. Since each device has an input buffer and two output buffers (output is double buffered), each of the 63 devices has available an average of about 13 charac- ters for input and 13 characters for each output buffer. Since there is continual pressure for new features in the TIP and for old features to work more conveniently, the space available for device buffers is steadily decreasing. There seem to be two ways to increase the space available for device buffers; the first is to get more core memory; the second is to modularize the program so that unneeded features can be removed from particular sites. For instance, the 2741 code and character conversion tables might be removed from a site at which they were never used. You always have the option of getting more core for your TIP; we are presently working on the latter method and should have it ready in a few months. In the mean time, the space available for device buffers will probably continue to slowly diminish. The nominal (untailored) buffer sizes are presently about as follows: device input (characters) output (characters/buffer) 1-3 60 56 4-7 28 27 8-15 20 20 16-32 12 13 33-63 6 6 Echoing. The TIP's echoing capability has been a controversial item in the past. We have recently fixed it up a little and we think that if you try it now, you'll like it a lot better. Unfortunately, "@@" is still not echoed correctly very often; this is a bug and we are going to fix it, but it's hairy to fix. We will shortly be removing three of the ECHO commands (ECHO ALL, ECHO HALFDUPLEX, and ECHO NONE) and be slightly changing the meaning of the two other ECHO commands (ECHO REMOTE and ECHO LOCAL). We will also add two new ECHO commands (PHYSICAL HALFDUPLEX and PHYSICAL FULLDUPLEX.) Thus the new set of ECHO commands will be: @PHYSICAL HALFDUPLEX @PHYSICAL FULLDUPLEX @ECHO LOCAL @ECHO REMOTE [Page 3]
RFC # 365 July 11, 1972 The ECHO LOCAL and ECHO REMOTE commands will probably be ignored for physical halfduplex devices. Therefore, for physical full- duplex devices, ECHO LOCAL and ECHO REMOTE will have the effect of declaring the device to be virtual halfduplex or virtual full- duplex. Devices which are known to be physical halfduplex (e.g., IBM 2741's) will come up in physical halfduplex mode. All other devices will come up in physical fullduplex mode and local echo mode (i.e., virtual halfduplex mode). Whenever a connection is opened, the TIP will automatically send off the current virtual echo mode to the server. Whenever a ECHO LOCAL or ECHO REMOTE command is given, the virtual mode will be appropriately updated and forwarded to the server. When the Telnet ECHO (code 132) (=virtual fullduplex) or Telnet NO ECHO (code 131) (=virtual half- duplex) characters are received by the TIP, it will follow the following rules: ECHO received and TIP is physical halfduplex -- NO ECHO sent to server TIP is virtual halfduplex -- ECHO sent to server and mode changed to virtual fullduplex TIP is virtual fullduplex -- nothing NO ECHO received and TIP is physical halfduplex -- nothing TIP is virtual halfduplex -- nothing TIP is virtual fullduplex -- NO ECHO sent to server and mode changed to virtual halfduplex When a connection is broken, devices in physical fullduplex mode will be reset to virtual halfduplex mode. Some other command changes we are planning to make. -------------------------------------------------- 1. PROTOCOL TO LOGIN will be removed. It has been replaced by LOGIN. 2. LOGIN will take a parameter, the Host number, so it will not be necessary to give both HOST and LOGIN commands. Some things which we are presently doing. ---------------------------------------- [Page 4]
RFC # 365 July 11, 1972 1. When a terminal hangs up, any captured devices will be given back. 2. Output to high speed devices will be possible. 3. Data sets will automatically be hung up when the caller disconnects even though the caller never "logged in". 4. 202C modems will work. 5. Major improvements on the magnetic tape option. 6. Trying to find the "R half" of the "R T CLOSED" message. 7. We have received numerous complaints that the TIP once in a while loses an allocate. We will fix this or else demonstrate it's not the TIP's fault. Some things we are thinking about. --------------------------------- 1. Adding a lower case capability for Model 33 Teletypes. 2. Adding a mechanism so the TIP's status or a device's status (e.g., its device number) can be obtained by the user. Each of the above mentioned changes will be preceded by notification via the NEWS and we plan to issue frequent updates to the TIP User's Guide from now on. We are trying hard to improve the TIP. If you've got a suggestion (especially if it doesn't take any memory), let me hear from you. Regards, < signed "Dave" > David C. Walden Bolt Beranek and Newman Inc. July 11, 1972 [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by BBN Corp. under the ] [ direction of Alex McKenzie. 1/97 ] [Page 5]
mirror server hosted at Truenetwork, Russian Federation.