Movatterモバイル変換

Network Working Group                 David WaldenRequest for Comments #365             Bolt Beranek and Newman Inc.NIC # 10607                           July 11, 1972Categories:Updates:Obsoletes:A LETTER TO ALL TIP USERSDear TIP Users,     You will shortly be sent a revised version of the "TIP User'sGuide."  Besides now having a loose leaf format, mainly descriptionsof new commands have been added.Appendix B will be an alphabeticallist 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 TAPEThe MAG commands are, of course, not relevant to users of TIPs withoutthe magnetic tape option.     A TIP system including the above commands has been in operationsince late June.  We think this system is a substantial improvementover previous versions.                                                                [Page 1]

RFC # 365                                                  July 11, 1972     In case you've not been keeping track, there are now eleven TIPsin the ARPA Network.  These are ETAC, GWC, AMES, ARPA, MITRE, NBS,BBN, USC, NOAA, ROME, and SAAC.  Also, a TIP will soon be installed atCCA.     I'll now briefly discuss a number of topics I think may beinteresting to you.     Getting TIP status information.  As we develop new features forthe TIP and fix bugs, we are continually releasing new versions of theTIP program.  We do this by just reloading your TIP when you're notlooking (i.e., when no one is using your TIP).  In the future we willnotify you whenever a new version of the TIP program is loaded intoyour TIP by adding a tiny "status message" to the "HELLO" you get whenyou "log onto" the TIP.  This status message will usually be merelythe TIP's version number; however, occasionally the message willindicate (by typing "NEWS") that there is some news about the TIP'sstatus which you should read before continuing your session with theTIP.  The NEWS can be retrieved by typing the command @NEWS which willICP to a special socket at BBN's TENEX or PDP-1D which will print thenews.  Of course, either of these systems may sometimes be down, butwe won't worry about the problem until we see how serious it is.     To whom to complain or make suggestions.  Many of you have hadoccasion to complain about the operation of your TIP system or to makesuggestions for its improvement.  All too frequently, however, thesecomplaints have been directed to the Host system you are using fromthe TIP instead of to us.  BBN maintains a Network Control Centerwhich is always manned.  Its telephone number is 617-661-0100.  AllTIP problems should be reported immediately to the Network ControlCenter.  If you have a suggestion for a new command, or if you thinkyou've found a subtle bug in the TIP program, ask to talk to DaveWalden or Bernie Cosell when you call the Network Control Center.     Device buffers. In general, each TIP MLC port has a differentsize buffer allocated to it and therefore to the device connected tothe port.  Devices which operate at higher speeds, of course, requirelarger buffers, especially output buffers.  If you need more bufferingthan you have (frequently indicated by output coming in short bursts),try to arrange with whomever is locally responsible for the TIP you'reusing to come in through a port with a larger buffer allocation.  Ifnecessary, this person can arrange with us to specially tailor thebuffer allocation for your TIP.                                                                [Page 2]

RFC # 365                                                  July 11, 1972     There are presently only about 2500 characters of buffersavailable for the TIPs terminal devices.  Since each device has aninput buffer and two output buffers (output is double buffered), eachof the 63 devices has available an average of about 13 charac- tersfor input and 13 characters for each output buffer.  Since there iscontinual pressure for new features in the TIP and for old features towork more conveniently, the space available for device buffers issteadily decreasing.  There seem to be two ways to increase the spaceavailable for device buffers; the first is to get more core memory;the second is to modularize the program so that unneeded features canbe removed from particular sites.  For instance, the 2741 code andcharacter conversion tables might be removed from a site at which theywere never used.  You always have the option of getting more core foryour TIP; we are presently working on the latter method and shouldhave it ready in a few months.  In the mean time, the space availablefor device buffers will probably continue to slowly diminish.     The nominal (untailored) buffer sizes are presently about asfollows:     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 controversialitem in the past.  We have recently fixed it up a little and we thinkthat 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 weare 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 meaningof the two other ECHO commands (ECHO REMOTE and ECHO LOCAL).  We willalso add two new ECHO commands (PHYSICAL HALFDUPLEX and PHYSICALFULLDUPLEX.) Thus the new set of ECHO commands will be:     @PHYSICAL HALFDUPLEX     @PHYSICAL FULLDUPLEX     @ECHO LOCAL     @ECHO REMOTE                                                                [Page 3]

RFC # 365                                                  July 11, 1972The ECHO LOCAL and ECHO REMOTE commands will probably be ignored forphysical halfduplex devices.  Therefore, for physical full- duplexdevices, ECHO LOCAL and ECHO REMOTE will have the effect of declaringthe device to be virtual halfduplex or virtual full- duplex. Deviceswhich are known to be physical halfduplex (e.g., IBM 2741's) will comeup in physical halfduplex mode.  All other devices will come up inphysical fullduplex mode and local echo mode (i.e., virtual halfduplexmode).  Whenever a connection is opened, the TIP will automaticallysend off the current virtual echo mode to the server.  Whenever a ECHOLOCAL or ECHO REMOTE command is given, the virtual mode will beappropriately updated and forwarded to the server.  When the TelnetECHO (code 132) (=virtual fullduplex) or Telnet NO ECHO (code 131)(=virtual half- duplex) characters are received by the TIP, it willfollow 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                                        halfduplexWhen a connection is broken, devices in physical fullduplex mode willbe 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, 19721.  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 bynotification via the NEWS and we plan to issue frequent updates to theTIP User's Guide from now on.     We are trying hard to improve the TIP.  If you've got asuggestion (especially if it doesn't take any memory), let me hearfrom 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]