Letter to All TIP Users

D.C. Walden

doi:10.17487/RFC0365

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

This is a modified version of the Internet RFC suitable for machine-translating. Original version is available here: RFC365

UNKNOWN

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 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:

                                                                [Page 3]


RFC # 365                                                  July 11, 1972

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]

Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.