RFC96 日本語訳

0096 An Interactive Network Experiment to Study Modes of Access theNetwork Information Center. R.W. Watson. February 1971. (Format: TXT=11334 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                           NIC 5739
Request for Comments: 96                               Richard W. Watson
Category: Informational                                          SRI-ARC
                                                        12 February 1971

コメントを求めるワーキンググループNIC5739要求をネットワークでつないでください: 96リチャードW.ワトソンカテゴリ: 情報の様アーク1971年2月12日

An Interactive Network Experiment to Study Modes of Access the Network
Information Center

アクセスネットワークインフォメーション・センターのモードを研究する対話的なネットワーク実験

1.   Introduction

1. 序論

     This NWG/RFC outlines the framework for a simple interactive
experiment to study modes of access to the Network Information Center
(NIC). A detailed specification for the initial access conventions to
the NIC is contained in NWG/RFC 97, NIC (5740,). The initial online
service to be provided by the Network Information Center are oriented
around the SRI-ARC (ARC) Online System, typewriter version - NLS(T).
These services will involve creation, manipulation, searching, and
distribution of symbolic material (text initially). The initial Online
System was display oriented and considerable development has gone into
the study of features required for a comfortable interface to the user.
In preparation for use with the Network Information Center, a typewriter
oriented version has been developed. Assuming good computer response and
a typewriter terminal operating at 30 char/sec, the system provides
powerful and comfortable to use capabilities for handling structured
textual material.

このNWG/RFCは、Networkインフォメーション・センター(NIC)へのアクセスの方法を研究するために簡単な対話的な実験のためのフレームワークについて概説します。 イニシャルのための仕様詳細がコンベンションにアクセスする、NIC、NICが含まれたコネNWG/RFC97である、(5740、) Networkインフォメーション・センターに提供しているのは、SRI-ARCの周りで指向(ARC)のオンラインSystemです、タイプライタバージョンということである初期のオンラインサービス--NLS(T)。 これらのサービスがシンボリックな材料の作成、操作、探すこと、および分配にかかわる、(テキスト、初めは) 初期のOnline Systemは適応するディスプレイでした、そして、かなりの開発が快適なインタフェースに必要である特徴の研究をユーザに調べました。 Networkインフォメーション・センターとの使用に備えて、タイプライタ指向のバージョンを開発してあります。 30炭/秒のときに作動しながら良いコンピュータ応答とタイプライタが端末であると仮定して、システムは構造化された原文の材料を扱うのに能力を使用するのにおいて強力であって、快適な状態で提供されます。

     The question to which the experiment, to be described below,
addresses itself is to determine how to extend these capabilities
through the network to users at remote sites, possibly operating 10
char/sec and higher speed terminals through fairly heavily loaded
systems. This experiment will also provide useful information about the
interactive characteristics of the network, and guidelines for designers
of other interactive systems to be used with the network. We propose
that this experiment will be conducted with the assistance and
cooperation of one other site. We estimate that the experiment will
require about three calendar months. In order to minimize the resources
required for the experiment, we will collect meaningful response time
statistics that are easy to obtain with presetly existing metering
facilities in the SRI and cooperating site systems, and network
performance measuring facilities. We will not conduct formal
productivity studies with the users of the connection, but will obtain
their subjective impressions on use of the various connection modes. The
result will be data indicating the costs and benefits obtained using the
types of access described below. We would expect that this information
would be useful to sites in determining how they want to implement
access to the NIC and other interactive sites.

実験が以下で説明されるためにそれ自体を扱う質問はネットワークを通してこれらの能力をリモートサイトのユーザに与える方法を決定することです、ことによると大いに公正にロードされたシステムを通して10炭/秒と、より高い速度端末を操作して。また、この実験は、ネットワークと共に使用されるためにネットワークの対話的な特性、および他の対話的なシステムのデザイナーへのガイドラインに関する役に立つ情報を提供するでしょう。 私たちは、この実験が他の1つのサイトの支援と協力によって行われるよう提案します。 私たちは、実験がおよそ3つの暦月を必要とすると見積もっています。 実験に必要であるリソースを最小にするために、私たちは施設を測定しながら、重要なあらかじめセットするのがSRIで施設を計量しながら存在していて、協力している状態でサイトシステム、およびネットワーク性能を入手しやすい応答時間統計を集めるつもりです。 私たちは、接続のユーザと共に正式な生産性研究を行いませんが、様々な接続モードの使用のときに彼らの主観的印象を得るつもりです。 結果は以下で説明されたアクセスのタイプを使用することで得られたコストと利益を示すデータになるでしょう。 私たちは、それらがどのようにNICと他の対話的なサイトへのアクセスを実装したがっているかを決定する際にこの情報がサイトの役に立つと予想するでしょう。

                                                                [Page 1]

NETWORK WORKING GROUP           RFC #96                         NIC 5739

[1ページ] ネットワーク作業部会RFC#96NIC5739

During the period of the experiment, other sites will want to access the
NIC as they come up on the network. We would recommend a simple
approach, such as described in Section 2b, initially with a possible
change later if the experiment indicates improved response and/or human
factors coupling can be obtained with one of the other approaches,
NWG/RFC 97, NIC (5740,) specifies this initial access approach in
detail.

実験の期間、彼らがネットワークに近づくとき、他のサイトはNICにアクセスしたくなるでしょう。 私たちは、より遅く実験が改良された応答を示すなら初めはセクション2bで可能な変化で説明されるように簡潔な解決法を推薦するでしょう、そして、NWG/RFC97、他のアプローチの1つで人間の要素カップリングを入手できます、そして、NICは詳細にこの初期のアクセスアプローチを指定します(5740)。

2.   Getting Connected to the Network

2. ネットワークに関させます。

   2a.   Introduction

2a。 序論

        There are three basic approaches to allowing remote sites to
   connect to the NIC through the network, which we can call User
   Program Telnet, NLS(T) Front End, Monitor Telnet. Each of these is
   discussed below. Each approach requires code which will run in the
   remote host.

リモートサイトが私たちがUser Program Telnetと呼ぶことができるネットワークを通してNICに接続するのを許容することへの3つの基本的なアプローチがあります、NLS(T)の前部End、Monitor Telnet。 以下でそれぞれのこれらについて議論します。 各アプローチはリモートホストに立候補するコードを必要とします。

        We assume that standard conventions for Telnet programs will be
   specified by the Network Working Group. In the companion paper
   (NWG/RFC 97), NIC (5740,)) we include recommended conventions on
   solving those problems which we are aware exists relative to initial
   NIC access, although we have tried to specify conventions useful more
   generally. The NLS(T) Front End Program would interface to the Telnet
   Program.

私たちは、Telnetプログラムのための一般的なコンベンションがNetwork作業部会によって指定されると思います。 仲間紙(NWG/RFC97)では、NIC(5740)) 私たちはそれらの問題を解決するときのお勧めのコンベンションを入れます(初期のNICアクセスに比例して存在しています私たちが意識している)、私たちは、より一般に役に立った状態でコンベンションを指定しようとしましたが。 NLS(T) 前部End ProgramはTelnet Programに連結するでしょう。

        We assume that no matter which approach is taken, the software
   at the ARC end use the information obtained during the connection
   process to log-in the remote terminal under a general account and
   will place the terminal user in the NIC version of NLS, which we will
   call NLS(NIC) for short. The NLS(NIC) will ask the terminal user for
   his initials. The remote user then has access to all NIC facilities.

私たちは、どのアプローチを取っても、情報が接続の間に得たARC最終用途におけるソフトウェアが一般会計の下で遠隔端末にログインするために処理して、私たちが略してNLS(NIC)と呼ぶつもりであるNLSのNICバージョンに端末ユーザを置くと思います。 NLS(NIC)は彼のイニシャルを端末ユーザに求めるでしょう。 そして、リモート・ユーザーはすべてのNIC施設に近づく手段を持っています。

        The initial typewriter oriented system accepts commands of the
   general form:

初期のタイプライタ指向のシステムは一般的な形式のコマンドを受け入れます:

   <command words> <operand> <delimiter> ... <operand> <delimiter>

<コマンドは><オペランド><デリミタ>を言い表します… <オペランド><デリミタ>。

        The <command words> is usually two words, the first to indicate
   a general operation class, and the second to indicate a general data
   structure type to be operated on. The <operand>s specify specific
   data entities to be operated upon, or instructions to adjust NLS
   parameters.

通常、<コマンド単語>は2つの単語(操作される一般データ構造タイプを示す一般的な操作のクラス、および2番目を示す1番目)です。 <オペランド>sは、NLSパラメタを調整するために操作される特定のデータ実体、または指示を指定します。

                                                                [Page 2]

NETWORK WORKING GROUP           RFC #96                         NIC 5739

[2ページ] ネットワーク作業部会RFC#96NIC5739

        The system at ARC is full duplex and allows the user to type the
   first character of the command words and the system immediately echos
   the remaining characters as feedback and support for the user. Other
   feedback is echoed where appropriate. The question we need to answer
   is what changes in this system will be required to suit it to the
   network and remote site constraints. We now look at problems existing
   at the remote sites.

ARCのシステムは、全二重であり、ユーザがコマンド単語とシステムの最初の文字をタイプするのを許容します。すぐに、フィードバックとしての残っているキャラクタとユーザのサポートはこだまします。 他のフィードバックは適切であるところで反映されます。 私たちが、答える必要があるという質問はこのシステムにおけるどんな変化がネットワークとリモートサイト規制にそれを合わせなければならないかということです。 私たちは、現在、問題がリモートサイトに存在するのを見ます。

        To gain connection to the NIC we assume that the user logs into
   his local system and calls up a subsystem or cusp. This subsystem or
   system program, Telnet program will be used to access other sites as
   well. The remote terminal and its controlling software system can
   operate in three basic modes as seen by the host subsystems

接続をNICに獲得するために、私たちは、ユーザが彼のローカルシステムにログインして、サブシステムか尖頭を呼び出すと思います。 このサブシステムかシステムプログラム、Telnetプログラムが、また、他のサイトにアクセスするのに使用されるでしょう。 遠隔端末とその制御ソフトウェア・システムはホストサブシステムで見られるように3つの基本のモードで作動できます。

      Case 1 - Character at a time half duplex

ケース1--時間半二重におけるキャラクター

      Case 2 - Character at a time full duplex

ケース2--時間全二重におけるキャラクター

      Case 3 - Line at a time half duplex

ケース3--時間半二重における線

        Although line at a time is full duplex is a logical possibility,
   no such approach is in general use and we ignore it in the following
   discussion.

一度に系列は全二重が論理的な可能性であるということですが、どんなそのようなアプローチも一般に、使用と私たちが以下の議論でそれを無視するということではありません。

   In the discussions to follow, in Section 2b, 2c and 2d, we describe
   the modes of access which we would like to investigate
   experimentally.  We want to study user reaction with 10 char/sec, 15
   char/sec, and 30 char/sec devices.

続く議論、セクションの2b、2c、および2dでは、私たちは実験的に調査したいと思うアクセスの方法を説明します。 10炭/秒、15炭/秒、および30台の炭/秒のデバイスとのユーザ反応を研究したいと思います。

   2b.   User Program Telnet

2b。 ユーザ・プログラムtelnet

        Consider the above classes of terminal in turn and the ways the
   Telnet program might handle communications between them and the NIC.
   The Telnet program might allow both full and half duplex
   communication as specified by the user.

順番に上のクラスの端末を考えてください。そうすれば、Telnetがプログラムを作る方法はそれらとNICとのコミュニケーションを扱うかもしれません。 プログラムが両方をいっぱいに許容するかもしれないTelnetとユーザによって指定される半二重通信。

      2b1.   Case 1 - Character at a Time Full Duplex

2b1。 ケース1--時間全二重におけるキャラクター

            The simplest approach would be for the Telnet program to
      take each character received from the terminal (except a special
      character or character sequence needed to escape back to the
      terminals host system), convert the code to ASCII and transmit it
      as a message to NLS(NIC). NLS(NIC) would handle all character
      echoing and transmit echo messages back to the Telnet for actual
      transmission to the terminal in the appropriate terminal code.
      This mode of communication involves full duplex transmission user
      to user and is probably the severest test of the interactive
      characteristics of the host-network-host system.

最も簡単なアプローチは、Telnetプログラムが端末(系列が端末に逃げて戻る必要があった特殊文字かキャラクタを除いて、システムをホスティングする)から受け取られた各キャラクタを連れて行って、コードをASCIIに変換して、メッセージとしてNLS(NIC)にそれを伝えるだろうことです。 NLS(NIC)は端末への実際のトランスミッションのために適切な端末のコードですべてのキャラクタ反響を扱って、エコーメッセージをTelnetに送って戻すでしょう。 コミュニケーションのこのモードは、全二重通信ユーザにユーザにかかわって、たぶんホストネットワークホストシステムの対話的な特性の最も辛いテストです。

                                                                [Page 3]

NETWORK WORKING GROUP           RFC #96                         NIC 5739

[3ページ] ネットワーク作業部会RFC#96NIC5739

            Depending on loading at the remote host, on the network, and
      at ARC, round trip delay for simple character echoing may be
      several seconds. Experience in communication between the old ARC
      940 and a heavily loaded PDP-10 at Utah showed occasional delays
      on the order of 4 or 5 seconds and longer for single character
      echoing. Human factors considerations in use of NLS(NIC) indicate
      that such delays would be frustrating to the user. A more cageful
      study of this mode of communication should give a base against
      which to measure the other modes of communication.

リモートホストにおいてネットワークの上と、そして、ARCでロードするのによって、簡単なキャラクタ反響のための周遊旅行遅れは数秒であるかもしれません。 古いARC940とユタの大いに積み込まれたPDP-10とのコミュニケーションの経験は、時々の遅れが4秒か5秒の注文と単独のキャラクタのための、より長い間反響するのを示しました。 NLS(NIC)で使用中の人間の要素問題は、ユーザにとって、そのような遅れがいらだたしいのを示します。 コミュニケーションのこのモードの、よりcagefulな研究はコミュニケーションの他のモードを測定するベースを与えるべきです。

      2b2.   Case 2 - Character at a Time Half Duplex

2b2。 ケース2--時間半二重におけるキャラクター

         There are two subcases which we treat identically:

私たちが同様に扱う2つの「副-ケース」があります:

         i) The Telnet program sees a half duplex terminal.

i) Telnetプログラムは、半二重が端末であることを見ます。

         ii) The Telnet program sees a full duplex terminal, but
         provides echoing so as to make the terminal half duplex as seen
         by NIC.

ii) Telnetプログラムは、全二重が端末であることを見ますが、NICによって見られるように端末の半二重を作るために反響しながら、提供されます。

         With the character at a time half duplex case the NIC program
         will operate in two modes:

時間半二重ケースのキャラクタと共に、NICプログラムは2つのモードで作動するでしょう:

         a) short mode

a) 短いモード

         b) long mode

b)長いモード

         In short mode the user will type in the command and receive on
         his terminal only the characters echoed by his system and the
         NIC response to the command.

短いモードで、ユーザは、コマンドをタイプして、彼の端末だけで彼のシステムによって言葉を繰り返されたキャラクタとコマンドへのNIC応答を受けるでしょう。

         In long mode. the user will receive feedback from NIC at an
         appropriate point in the command. We want to see how novice and
         experienced users feel about working in these two modes, given
         the delays in the system response.

長さでは、モードユーザは適切なポイントでNICからコマンドで反響を調べるでしょう。 初心者と経験のあるユーザがどう探るかがこれらの2つのモードで働いているのを見たいと思います、システム・レスポンスの遅れを考えて。

      2b3.   Case 3 - Line at a Time Half Duplex

2b3。 ケース3--時間半二重における線

         From the point of ciew of the NIC this case is essentially the
         same as Case 2.  From the point of ciew of the network this
         case is a more efficient use fo the network as the messages are
         longer.  This case is also more efficient for the user host
         system as it will require fewer calls to the Telnet subsystem;
         response for Case 3 may be better than Case 2.

NICのciewの先から、本件はCase2と本質的には同じです。 ネットワークのciewの先から、本件はメッセージが、より長いときに、より効率的な使用がネットワークをfoするということです。 また、Telnetサブシステムにより少ない呼び出しを必要とするので、ユーザー・ホストシステムには、本件も、より効率的です。 Case3のための応答はCase2より良いかもしれません。

                                                                [Page 4]

NETWORK WORKING GROUP           RFC #96                         NIC 5739

[4ページ] ネットワーク作業部会RFC#96NIC5739

   2c.   The NLS(T) Front End

2c。 NLS(T)フロントエンド

           In this mode of communication, the subsystem which handles
      communication with the NIC is to perform some of the interactive
      and other tasks now performed by NLS(T). The type of tasks to be
      performed are echoing of the characters typed and the additional
      feedback characters for the full spell out of the command words,
      parsing of the command string, error handling where appropriate,
      and the sending of a parsed string as a message to NLS(T). If it
      should turn out that this mode of communication is the one
      preferred by sites, we would expect to supply an example version
      of the Front End program written in some language to serve as a
      model for implementation. The Network Working Group may want to
      give further study to a standard language for specifying such
      programs as indicated in NWG/RFC 51, NIC (4752,).

コミュニケーションのこのモードで、NICとのコミュニケーションを扱うサブシステムは現在NLS(T)によって実行されているインタラクティブと他のタスクのいくつかを実行することです。 実行されるべきタスクのタイプは、完全なスペルの間、適切であるところでコマンド単語、コマンドストリングの構文解析、エラー処理からタイプされた文字と追加フィードバック文字に反響して、NLS(T)へのメッセージとしての分析されたストリングの発信です。 コミュニケーションのこのモードがサイトによって好まれたものであると判明するなら、私たちは、実装のために手本になるように何らかの言語で書かれたFront Endプログラムの例のバージョンを供給すると予想するでしょう。 作業部会が与えたがっているかもしれないNetworkはNWG/RFC51にみられるようにそのようなプログラムを指定するためにさらに標準語に研究します、NIC(4752)。

   2d.   Monitor Telnet

2d。 モニターtelnet

           Much of the response delay in the experiments of Section 2b
      is expected to result from the fact that the Telnet described
      there is a user program. We will run the experiments of Section 2b
      with the appropriate Telnet routines resident as a part of the
      user host monitor.

セクション2bの実験における、応答遅れの多くがそこで説明されたTelnetがユーザ・プログラムであるという事実から生じることが期待されます。 私たちはユーザー・ホストモニターの一部として適切なTelnetルーチンの居住者とのセクション2bの実験を実行するつもりです。

          [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Henrik Johansson 4/97 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Henrikヨハンソン4/97によるオンラインRFCアーカイブへの]

                                                                [Page 5]

[5ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

生年月日などで年を選択するときのサンプルコード

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る