RFC89 日本語訳

Network Working Group                                        B. Metcalff
Request for Comments: 89                                           MITDG
NIC: 5697                                                19 January 1971

Metcalffがコメントのために要求するワーキンググループB.をネットワークでつないでください: 89MITDG NIC: 5697 1971年1月19日

                  SOME HISTORIC MOMENTS IN NETWORKING

ネットワークにおけるいくつかの歴史的瞬間

   While awaiting the completion of an interim network control program
   (INCP) for the MIT MAC Dynamic Modeling/Computer Graphics PDP-6/10
   System (MITDG), we were able to achieve a number of 'historic moments
   in networking' worthy of some comment.  First, we were able to
   connect an MITDG terminal to a Multics process making it a Multics
   terminal.  Second, we successfully attached an MITDG terminal to the
   Harvard PDP-10 System thereby enabling automatic remote use of the
   Harvard System for MIT.  Third, we developed primitive mechanisms
   through which remotely generated programs and data could be
   transmitted to our system, executed, and returned.  Using these
   mechanisms in close cooperation with Harvard, we received graphics
   programs and 3D data from Harvard's PDP-10, processed them repeatedly
   using our Evans & Sutherland Line Drawing System (the E&S), and
   transmitted 2D scope data to Harvard's PDP-1 for display.

MIT MAC Dynamic Modeling/コンピュータGraphics PDP-6/10 System(MITDG)のために当座のネットワーク・コントロール・プログラム(INCP)の完成を待っている間、私たちは何らかのコメントにふさわしい状態で多くの'ネットワークにおける歴史的瞬間'を達成できました。 まず最初に、私たちはそれをMultics端末にするMulticsの過程にMITDG端末をつなげることができました。 2番目に、私たちは、ハーバードSystemのMITの自動リモート使用を可能にしながら、首尾よくその結果、ハーバードPDP-10 SystemにMITDG端末を取り付けました。 3番目に、私たちは、ほんの少し発生しているプログラムとデータを実行された私たちのシステムに放送できた原始のメカニズムを開発して、戻りました。 緊密に提携してハーバードがあるこれらのメカニズムを使用して、私たちは、ハーバードのPDP-10から画像プログラムと3Dデータを受け取って、繰り返して、私たちのエヴァンスとサザーランド線Drawing System(E&S)を使用することでそれらを処理して、表示のために2D範囲データをハーバードのPDP-1に送りました。

The IINCP

IINCP

   Our experiments were run on the MITDG PDP-6/10 using what we have
   affectionately called our 'interim interim NCP' (IINCP).  Under the
   IINCP the IMP Interface is treated as a single-user I/O device which
   deals in raw network messages.  The software supporting necessary
   system calls includes little more than the basic interrupt-handling
   and buffering schemes to be used later by the NCP.  In short, the
   user-level programs which brought us to our historic moments were
   written close to the hardware with full knowledge of IMP-HOST
   Protocol (BBN 1822).  When the INCP and NCP are completed, these
   programs can be pruned considerably (80%).  The exercise of writing
   programs which conform to IMP-HOST Protocol was not at all wasted.
   Only now can those of us who are not writing the NCP begin to grasp
   the full meaning of RFNM's and their use in flow control.  The
   penalties for ignoring an impatient IMP, for failing to send NOOPS
   (NO-OPS) when starting up, and for blasting data onto the Network
   without regard for RFNM's are now well understood.

私たちの実験は私たちが愛情を込めて私たちの'当座の当座のNCP'(IINCP)と呼んだことを使用するMITDG PDP-6/10における走行でした。 IINCPの下では、IMP Interfaceは生のネットワークメッセージを扱うシングルユーザー入出力装置として扱われます。 必要なシステムコールを支持するソフトウェアは、後でNCPによって使用されるためにただ基本的な割込み処理とバッファリング方式を含んでいます。 要するに、私たちを私たちの歴史的瞬間に導いたユーザレベルプログラムはIMP-HOSTプロトコル(BBN1822)に関する完全な知識があるハードウェアの近くに書かれました。 INCPとNCPが完成するとき、これらのプログラムからかなり(80%)余計なものを取り除かれることができます。 IMP-HOSTに一致しているプログラムにプロトコルを書く運動は全く浪費されませんでした。 NCPを書いていない私たちの人は現在、RFNMの完全な意味とフロー制御における彼らの使用を理解するだけであり始めることができます。 RFNMのものが現在よく理解されているので始動するときNOOPS(OPSがない)を送らないで、関係なしでNetworkにデータを爆破するためにせっかちなIMPを無視するための刑罰。

The Multics Connection

Multics接続

   Our quest for historic moments began with the need to demonstrate
   that the complex hardware-software system separating MITDG and
   Multics was operative and understood.  A task force (Messrs. Bingham,

歴史的瞬間を求める私たちの探索は、MITDGとMulticsを切り離す複雑なハードウェアソフトウェア・システムが影響を及ぼしていたのを示す必要性をもって始まって、分かりました。 特別委員会、(ビンガムさん

Metcalff                                                        [Page 1]

RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971

いくつかの歴史的瞬間のネットワーク1971年1月19日のMetcalff[1ページ]RFC89

   Brodie, Knight, Metcalfe, Meyer, Padlipsky and Skinner) was
   commissioned to establish a 'polite conversation' between a Multics
   terminal and an MITDG terminal.

ブローディ、Knight、メトカルフェ、マイヤー、Padlipsky、およびスキナー) Multics端末とMITDG端末との'礼儀正しい会話'を設立するように任命されました。

   It was agreed that messages would be what we call 'network ASCII
   messages': 7-bit ASCII characters right-adjusted in 8-bit fields
   having the most significant bit set, marking, and padding.  In that
   Multics is presently predisposed toward line-oriented half-duplex
   terminals, it was decided that all transmissions would end with the
   Multics EOL character (ASCII <LINE FEED>).  To avoid duplicating much
   of the INCP in our experiment, the PDP-10 side of the connection was
   freed by convention from arbitrary bit-stream concatenation
   requirements and was permitted to associate logical message
   boundaries with network message boundaries (sic).  The 'polite
   conversation' was thus established and successful.

メッセージがいわゆる'ネットワークASCIIメッセージ'であるのに同意されました: 7ビットのASCII文字は最も重要なビットを設定する8ビットの分野、マーク、および詰め物で権利で適応しました。 Multicsが現在線指向の半二重端末に向かって前処理されるので、すべてのトランスミッションがMultics EOLキャラクタ(ASCII<LINE FEED>)と共に終わると決められました。 接続のPDP-10側面は、私たちの実験でINCPの多くをコピーするのを避けるために、任意のビットストリーム連結要件からのコンベンションによって解放されて、ネットワークメッセージ境界(原文のまま)論理メッセージ限界を関連づけることが許可されました。 '礼儀正しい会話'は、このようにして設立されていてうまくいきました。

   Multics, then, connected the conversation to its command processor
   and the PDP-10 terminal suddenly became a Multics terminal.  But, not
   quite:

次に、Multicsは会話をコマンドプロセサに接続しました、そして、PDP-10端末は突然Multics端末になりました。 しかし全くではなく、:

   First, in the resulting MITDG-Multics connection there was no
   provision for a remote QUIT, which in Multics is not an ASCII
   character.  This is a problem for Multics.  It would seem that an
   ASCII character or the network's own interrupt control message could
   be given QUIT significance.

まず最初に、結果として起こるMITDG-Multics接続には、支給が全くリモートQUITのためにありませんでした。(Multicsでは、QUITはASCII文字ではありません)。 これはMulticsのための問題です。 ASCII文字かネットワークの自己の割り込み制御メッセージにQUIT意味を与えることができたように思えるでしょう。

   Second, our initial driver program did not provide for RUBOUT.
   Because the Multics network input stream bypassed the typewriter
   device interface module (TTYDIM), line canonicalization was not
   performed.  In a more elegant implementation, line canonicalization
   could be done at Multics, providing the type-in editing conventions
   familiar to Multics users.  We fixed this problem hastily by having
   our driver program do local RUBOUT editing during line assembly, thus
   providing type-in editing conventions familiar to MITDG users.  It is
   clearly possible to do both local type-in editing and distant-host
   type-in editing.

2番目に、私たちの初期のドライバープログラムはRUBOUTに備えませんでした。 Multicsネットワーク入力ストリームがタイプライタ装置インタフェース・モジュール(TTYDIM)を迂回させたので、線canonicalizationは実行されませんでした。 より上品な実現では、線canonicalizationがMulticsにできました、Multicsユーザにとってなじみ深い状態で中のコンベンションを編集しているタイプを提供して。 私たちのドライバープログラムに線アセンブリの間、地方のRUBOUT編集をさせることによって、その結果、中でタイプするのをコンベンションを編集する前提とすることで私たちは急いで、MITDGユーザにとってなじみ深い状態でこの問題を修正しました。 地方の中でタイプする編集と冷ややかなホスト中でタイプする編集の両方をするのは明確に可能です。

   Third, we found that because of the manner in which our type-in
   entered the Multics system under the current network interface (i.e.
   not through TTYDIM), our remotely controlled processes were
   classified 'non-interactive' and thus fell to the bottom of Multics
   queues giving us slow response.  This problem can be easily fixed.

3番目に、私たちが中の私たちのタイプであるのが現在のネットワーク・インターフェース(すなわち、TTYDIMを通した)の下のMulticsシステムを入れた方法のためにそれを見つけて、私たちの離れて制御された過程は、遅い応答を私たちに与えながら、'非対話的に'分類されて、その結果、Multics待ち行列の底に落ちました。 容易にこの問題を修正できます。

The Harvard Connection

ハーバードの接続

   Connecting MITDG terminals to Multics proved to be easy in that the
   character-oriented MITDG system easily assembled lines for the
   Multics line-oriented system.  We (Messrs. Barker, Metcalfe) decided,

MITDG端末をMulticsにつなげるのはキャラクタ指向のMITDGシステムがMulticsの線指向のシステムのために容易に線を組み立てたので簡単であると判明しました。 私たち(バーカー、メトカルフェさん)は決めました。

Metcalff                                                        [Page 2]

RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971

いくつかの歴史的瞬間のネットワーク1971年1月19日のMetcalff[2ページ]RFC89

   therefore, that it would be worthwhile to connect the MITDG system to
   another character-oriented system, namely Harvard's PDP-10.  This
   move was also motivated by MITDG's desire to learn more about
   Harvard's new language system via MITDG's own consoles.

したがって、すなわち、別のキャラクタ指向のシステム、ハーバードのPDP-10にMITDGシステムを接続する価値があるでしょう。 また、この移動はMITDGの自身のコンソールを通してハーバードの新しい言語体系に関してもう少し学ぶMITDGの願望によって動機づけられました。

   It was found that Harvard had already provided an ASCII network
   interface to their system which accepted IMP-Teletype style messages
   as standard.  We quickly rigged up an IMP-Teletype message handler at
   MITDG and were immediately compatible and connected.  But not quite:

ハーバードが既にIMP-テレタイプスタイルメッセージが標準であると受け入れたそれらのシステムにASCIIネットワーク・インターフェースを供給したのが見つけられました。 私たちは、すぐにIMP-テレタイプ電報操作者をMITDGに整えて、すぐに、互換性があって、接続しました。 しかし、全く:

   First, Harvard runs the Digital Equipment Corporation (DEC) time-
   sharing system on their PDP-10 which has <control-C> as a QUIT
   character and <control-Z> as an end-of-file (EOF).  MITDG runs the
   MAC Incompatible Time-sharing System (ITS) which has <control-Z> as a
   QUIT character and <control-C> as an EOF.  This control character
   mismatch is convenient in the sense that typing <control-C> while
   connected to Harvard system through MITDG causes the right thing to
   happen - causes the execution of programs at Harvard to QUIT, as
   opposed to causing the driver program at MITDG to QUIT.  If, however,
   a Harvard program were to require that an EOF be typed, typing
   <control-Z> would cause ITS to stop the driver program in its tracks,
   leaving the Harvard EOF wait unsatisfied and the MITDG-Harvard
   connection severed.

まず最初に、ハーバードは、(12月)時にファイルの終り(EOF)としてQUITキャラクタとしての<コントロールC>と<コントロールZ>を持っているそれらのPDP-10でシステムを共有しながら、DECを経営している予定です。 MITDGはEOFとしてQUITキャラクタとしての<コントロールZ>と<コントロールC>を持っているMAC Incompatible Time-共有System(ITS)を走らせます。 この制御文字ミスマッチはMITDGを通してハーバードシステムに接続されている間、<コントロールC>をタイプすると起こる正しいものが引き起こされるという意味で便利です--ハーバードでプログラムの実行をQUITに引き起こします、MITDGでドライバープログラムをQUITに引き起こすことと対照的に。 しかしながら、ハーバードプログラムが、EOFがタイプされるのを必要とするなら、タイプ<コントロールZ>はITSにその場で、ハーバードEOF待ちを満たされていない状態でおいて、MITDG-ハーバードの接続が断ち切ったドライバープログラムを止めさせるでしょうに。

   Second, the Harvard system has temporarily implemented this remote
   network console interface feature using a DEC style pseudo-teletype
   (PTY).  This device vis-a-vis the DEC system behaves as a half-duplex
   terminal which wakes up on a set of 'break characters' (e.g., return,
   altmode) affording us an opportunity for an interesting experiment.
   The use of DDT (Dynamic Debugging Tool) is thereby restricted (though
   not prevented) in that break characters must be scattered throughout
   a DDT interaction to bring the PTY to life to cause DDT to do the
   right thing.  For example, to examine the contents of a core location
   one needs to type 'addr<altmode>' (address slash altmode) the altmode
   being only a call-to-action to the PTY.  To alter the contents of the
   opened location, one must then type '<rub-out>contents<return>'; the
   <rub-out> character deletes the previous action <alt-mode>, the
   contents are stashed in the open address, and the <return> signals
   the close of the address and PTY wake-up.  It would seem that DDT is
   a program that will separate the men form the boys in networking.

2番目に、ハーバードシステムは、12月のスタイル疑似テレタイプ(PTY)を使用することで一時このリモートネットワークコンソールインタフェース機能を実行しました。 12月のシステムと向かいあったこの装置はおもしろい実験の機会を私たちに提供しながら1セットの'区切り文字'(例えば、リターン、altmode)で目覚める半二重端末として反応します。 その結果、区切り文字がDDT相互作用の間中ときの正しいことをする原因DDTにPTYを生き返らせるように点在しなければならないので、DDT(ダイナミックなDebugging Tool)の使用は制限されます(防がれませんが)。 例えば、コア位置1のコンテンツを調べるのはタイプ'addr<altmode>'への呼び出しから動作であるにすぎない(アドレススラッシュaltmode)altmodeをPTYに必要とします。 次に、開かれた位置のコンテンツを変更するために、'<外で擦れ>コンテンツ<リターン>'をタイプしなければなりません。 <外で擦れ>キャラクタは前の動作<alt-モード>を削除します、そして、内容は開いているアドレスでしまっておかれます、そして、<リターン>はアドレスと上にPTY航跡の閉鎖に合図します。 DDTによる男性を切り離すプログラムがネットワークで少年を形成するということであるように思えるでしょう。

   Third, it was found that the response from the Harvard system at
   MITDG was seemingly as fast as could be expected from one of their
   own consoles.  This fact is particularly exciting to those who don't
   have a feel for network transit times when it is pointed out that
   such response was generated through two time-sharing systems, three
   user level processes, and three IMPs, all connected in series.

3番目に、MITDGのハーバードシステムからの応答がそれら自身のコンソールの1つから予想できたのと外観同じくらい速いのが見つけられました。 この事実は特にそのような応答が2台の時分割システムを通して発生したと指摘されるネットワークトランジット回数、3つのユーザレベルの過程、および3IMPs(シリーズで接続されたすべて)の感じを持っていない人におもしろいです。

Metcalff                                                        [Page 3]

RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971

いくつかの歴史的瞬間のネットワーク1971年1月19日のMetcalff[3ページ]RFC89

The Harvard-MIT Graphics Experiment

ハーバード-MITのグラフィックス実験

   At Harvard are a PDP-10 Time-sharing System and a graphics oriented
   PDP-1, both connected to Harvard's IMP.  At MITDG are a PDP-6/10
   Time-sharing System and an E&S Line Drawing System.  It was felt
   (Messre. Barker, Cohen, McQuillan, Metcalfe, and Taft) that the time
   had come to demonstrate that the network could make remote resource
   available - to give Harvard access to the E&S at MITDG via the
   network.  The protocol for such use of the network was as follows:
   (1)  MITDG starts its network monitor program listening.  (2)
   Harvard starts its PDP-10 transmitting a core image containing an
   arbitrary PDP-10 program (with an embedded E&S program in this case).
   (3)  MITDG receives the core image from Harvard and places it in its
   memory at the starting address specified, collecting messages and
   concatenating them appropriately.  (There was no word-length mismatch
   problem.)  (4) Upon collecting a complete image (word count sent
   first along with starting address), MITDG stashes its own return
   address in a specified location of the transmitted program's image
   and transfers control to another image location.  (5)  Upon getting
   control at MITDG, the transmitted program executes (in this case sets
   up and runs an E&S program) and before returning to the MITDG network
   monitor stashes in specified locations of its image the beginning and
   ending addresses of its result.  (6)  With control returned, the
   MITDG monitor program then transmits the results to a listening host
   which makes good use of them (in this case a PDP-1 which displays
   them).  (7)  Then the MITDG program either terminates, returns
   control back to the image (as in this case), or waits for more data
   and/or program.  The protocol was implemented in the hosts and used
   to run a Harvard-assembled version of the E&S Aircraft Carrier
   Program (written originally by Harvard's Prof. Cohen) at MITDG and to
   display the resulting dynamic display on Harvard's PDP-1 driven DEC
   scopes.  The Carrier Program was 'flown' from MITDG and the changing
   views thus generated appeared both at MITDG and Harvard.  The picture
   was observed to change (being transmission limited) on the order of
   twice each second (perhaps less often).  But all was not rosey:

ハーバードに、Systemとグラフィックスが適応させたPDP-10 Time-共有PDP-1、ハーバードのIMPに接続された両方があります。 MITDGに、PDP-6/10 Time-共有SystemとE&S線Drawing Systemがあります。 それは感じられました。(Messre。 バーカー、コーエン、マッキラン、メトカルフェ、およびタフト) 時間がネットワークがそうすることができたのを示すようになったのに、遠隔資源は利用可能になります--ネットワークを通してMITDGのE&Sへのハーバードのアクセスを与えるために。 ネットワークのそのような使用のためのプロトコルは以下の通りでした: (1) MITDGはネットワークモニタプログラムを聴き始めます。 (2) PDP-10はハーバードが任意のPDP-10プログラム(この場合、埋め込まれたE&Sプログラムがある)を含むコア・イメージを伝え始めます。 (3) MITDGはメッセージを集めて、適切にそれらを連結して、指定された開始アドレスに、ハーバードからコア・イメージを受け取って、それをメモリに置きます。 (語長ミスマッチ問題が全くありませんでした。) (4) 伝えられたプログラムのイメージと転送の指定された位置のそれ自身の返送先は完全なイメージ(最初に開始アドレスと共に送られた語の計数)、MITDG隠した物を集めるともう1つのイメージ位置に制御されます。 (5) 得るときに、MITDG(プログラムが実行して(この場合、E&Sプログラムをセットアップして、動かします)、イメージの指定された位置でMITDGネットワークモニター隠した物に始めと結末を返す前記述する結果の送信)で制御してください。 (6) 次に、コントロールを返していて、MITDGモニタプログラムは聴取ホストに結果を伝えます(有効に、それら(この場合それらを表示するPDP-1)を利用します)。 (7) 次に、MITDGプログラムが終わって、リターンがイメージに制御して戻られる、(この場合)、または、より多くのデータ、そして/または、プログラムのための待ち。 プロトコルは、ホストで実行されて、MITDGでE&S Aircraft Carrier Program(ハーバードのコーエン教授で、独創的に書く)のハーバードによって組み立てられたバージョンを走らせて、以前はハーバードのPDP-1の駆動12月の範囲の上によく結果として起こるダイナミックな表示を表示していました。 Carrier ProgramはMITDGから'飛ばされました'、そして、その結果視点が発生させた変化はMITDGとハーバードに現れました。 絵は1秒あたり二度(恐らくよりしばしば)の注文のときに変化する(制限されたトランスミッションである)と認められました。 しかし、すべてがroseyではありませんでした:

   First, it was observed that during the experiment prompting messages
   to the IMP-Teletypes were often garbled.  Most of the garbling can be
   attributed to the ASR-33 itself, some cannot.  There were no errors
   detected during data transmissions not involving the IMP-Teletypes.

まず最初に、観測されて、IMP-テレタイプへの実験プロンプティングメッセージの間のそれがしばしば誤り伝えられたということでした。 誤り伝えることの大部分をASR-33自身の結果と考えることができて、何かはそうすることができません。 IMP-テレタイプを伴わないデータ伝送の間に検出された誤りが全くありませんでした。

   Second, during attempts to fly the Carrier from Harvard, we stumbled
   across a yet undiagnosed intermittent malfunction of (presumably) the
   MITDG hardware and/or software which caused our network connection to
   be totally shut down by the system during bi-directional
   transmission.  This problem is currently under investigation.

2番目に、ハーバードからCarrierを飛ばす試みの間、私たちは(おそらく)双方向のトランスミッションの間にシステムで私たちのネットワーク接続を完全に止めたMITDGハードウェア、そして/または、ソフトウェアのまだ非診断された間欠故障を偶然見つけました。 この問題は現在、調査中です。

Metcalff                                                        [Page 4]

RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971

いくつかの歴史的瞬間のネットワーク1971年1月19日のMetcalff[4ページ]RFC89

   Third, the response of the total system was slow compared to that
   required to do real-time dynamic graphics.  One would expect that if
   this limitation is to be overcome, higher bandwidth transmission
   lines, faster host response to network messages, and/or perhaps a
   message priority system will be required.

リアルタイムのダイナミックなグラフィックスをするのに必要であるそれと比べて、3番目に、トータル・システムの応答は遅かったです。 人は、より高い帯域幅伝送路、ネットワークメッセージへの、より速いホスト応答、そして/または、恐らくメッセージ重点主義がこの制限が打ち勝たれることであるなら、必要であると予想するでしょう。

Metcalff                                                        [Page 5]

RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971

いくつかの歴史的瞬間のネットワーク1971年1月19日のMetcalff[5ページ]RFC89

36-Bit Words Transmitted
From Harvard's PDP-10 to
MITDG's PDP-10
                     +---------------+---------------+ Image control
                     |     -count    |    origin-1   | word.
                     +---------------+---------------|-
        Image:       |    start address of results   | | Filled in by
                     +-------------------------------+  -Harvard's
        Image+1:     |     end address of results    | | program during
                     +-------------------------------+-  its execution.
        Image+2:     |   ---------unused-----------  |  +--        -+
                     +-------------------------------+  |Filled in  |
        Image+3:     |      program stop address     |<-|by MITDG   |
                     +-------------------------------+  |for return |
        Image+4:     |     program start address     |  |of control.|
                     +-------------------------------+  +--       --+
        Image+5:     |                               |
                     +-------------------------------+
Image control word   |                               |
and image arrive in  |                               |
network size buffers |                               |
which are stripped of|                               |
marking and padding  |                               |
and concatenated.    |                               |
                     +-------------------------------+

ハーバードのPDP-10からMITDGのPDP-10+まで伝えられた36ビットのワーズ---------------+---------------+ イメージコントロール| -カウント| 起源-1| 言い表します。 +---------------+---------------|- イメージ: | 結果の開始アドレス| | +で、記入されます。-------------------------------+ ハーバードのイメージ+1: | 結果の終わりのアドレス| | +の間、プログラムを作ってください。-------------------------------+ その実行。 イメージ+2: | ---------未使用----------- | +-- -+ +-------------------------------+ |記入されます。| イメージ+3: | プログラム・ストップアドレス| <、-、|MITDG| +-------------------------------+ |リターンのために| イメージ+4: | プログラム開始アドレス| |コントロール| +について-------------------------------+、+----+ イメージ+5: | | +-------------------------------+ イメージ規制単語| | そして、イメージは中に到着します。| | ネットワークの規模バッファ| | どれ、奪い取られるか。| | マークと詰め物| | そして、連結されています。 | | +-------------------------------+

36-Bit Words Transmitted
From MITDG's PDP-10 to
Harvard's PDP-1
                      +---------------+---------------+
                      |               |    count      |
                      +---------------+---------------+
First word of results |                               |
Specified in Image+0. |                               |
                      |      results                  |
                      |                               |
                      |                               |
                      |                               |
                      |                               |
                      |                               |
                      |                               |
Last word of results  |                               |
specified in Image+1. |                               |
                      +-------------------------------+

MITDGのPDP-10からハーバードのPDP-1+まで伝えられた36ビットのワーズ---------------+---------------+ | | カウント| +---------------+---------------+ 結果の最初の単語| | イメージ+0で、指定されています。 | | | 結果| | | | | | | | | | | | | 結果の最後の単語| | Image+1では、指定されています。 | | +-------------------------------+

Metcalff                                                        [Page 6]

RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971

いくつかの歴史的瞬間のネットワーク1971年1月19日のMetcalff[6ページ]RFC89

General Comments

概評

   In producing 'network ASCII messages' we were required to bend over
   backwards to insert marking so that our last data bit could fall on a
   word boundary.  Surely there must be a better way.  The double
   padding scheme and its variants with or without marking should be
   considered.  Given the current hardware, it would seem that double
   padding with marking would be an improvement.  A simple(?) fix to
   host IMP interfaces enabling them to send only good data from a
   partially filled last word would permit a further improvement:
   marking and host-supplied single padding.

'ネットワークASCIIメッセージ'を生産する際に、私たちは、私たちの最後のデータ・ビットが語境界の責任となることができるようにマークを挿入するのを懸命になって努めなければなりませんでした。 確実に、より良い道があるに違いありません。 二重詰め物計画とマークのあるなしにかかわらずその異形は考えられるべきです。 現在のハードウェアを考えて、マークによる二重詰め物が改良であるように思えるでしょう。 部分的にいっぱいにされた締め括りの言葉から良いデータだけを送るのを可能にするホストIMPインタフェースへの簡単な(?)フィックスはさらなる改良を可能にするでしょう: マークしていてホストによって供給されたただ一つの詰め物。

   In these initial experiments Harvard used the IMP-Teletype message
   convention or what are call 'IMP ASCII messages' (without marking)
   because it would allow them to use IMP-Teletypes for logging in and
   testing.  Multics, on the other hand, used the standard network
   message format (with marking) to have Host-Host compatibility as per
   accepted protocols.  Both approaches have merit.  The IMP-Teletype
   message format should be changed to conform with the network standard
   - it should have marking.

これらの初期の実験では、ハーバードは、ログインして、テストするのにIMP-テレタイプ電報コンベンションかそれらを許容するでしょう、したがって、呼び出し'IMP ASCIIメッセージ'(マークのない)が使用への何であるかというIMP-テレタイプを使用しました。 他方では、Multicsは、受け入れられたプロトコルに従ってHost-ホストの互換性を持つのに、標準のネットワークメッセージ・フォーマット(マークがある)を使用しました。 両方のアプローチには、長所があります。 ネットワーク規格に従うためにIMP-テレタイプ電報形式を変えるべきです--それには、マークがあるべきです。

   Finally, we would like to announce our readiness to participate in
   experiments which will further extend our confidence and competence
   in networking, especially experiments which, like the preceding, will
   have very large returns with relatively small investment.

最終的に、さらにネットワークにおける私たちの信用と能力を申し上げる実験に参加する私たちの準備を発表したいと思います、特に比較的わずかな投資による非常に大きい収益が先行のようにある実験。

Roster of those participating

それらが参加する当直表

   Ben Barker              Harvard, BBN
   Grenville Bingham       MITDG
   Howard Brodie           MITDG
   Dan Cohen               Harvard
   Tim Knight              MITDG, MIT/AI
   John McQuillan          Harvard
   Bob Metcalfe            MITDG, Harvard
   Ed Meyer                Multics
   Mike Padlipsky          Multics
   Tom Skinner             Multics
   Ed Taft                 Harvard

ベンバーカーハーバード、BBN MITDGハワード飛び込みMITDGダンコーエンティムナイトMITDG、ハーバードMIT/AIジョンマッキランハーバードボブメトカルフェMITDG、グレンビルビンガムハーバードエドマイヤーMulticsマイクPadlipsky MulticsトムSkinner Multicsエドタフトハーバード

          [This RFC was put into machine readable form for entry]
          [into the online RFC archives by Lorrie Shiota, 10/01]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ロリー塩田によるオンラインRFCアーカイブへの10/01]

Metcalff                                                        [Page 7]

Metcalff[7ページ]