RFC33 日本語訳

0033 New Host-Host Protocol. S.D. Crocker. February 1970. (Format: TXT=44167 bytes) (Obsoletes RFC0011) (Updated by RFC0036, RFC0047) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                         S. Crocker
Request for Comments: 33                                            UCLA
                                                                 S. Carr
                                                      University of Utah
                                                                 V. Cerf
                                                                    UCLA
                                                        12 February 1970

コメントを求めるワーキンググループS.医者要求をネットワークでつないでください: 33 UCLA S.カーユタ大学V.サーフUCLA1970年2月12日

                         New HOST-HOST Protocol

新しいホスト兼ホストプロトコル

   Attached is a copy of the paper to be presented at the SJCC on the
   HOST-HOST Protocol.  It indicates many changes from the old protocol
   in NWG/RFC 11; these changes resulted from the network meeting on
   December 8, 1969.  The attached document does not contain enough
   information to write a NCP, and I will send out another memo or so
   shortly.  Responses to this memo are solicited, either as NWG/RFC's
   or personal notes to me.

HOST-HOSTプロトコルにSJCCに示される論文のコピーを添付します。 それはNWG/RFC11の古いプロトコルから多くの変化を示します。 これらの変化は1969年12月8日にネットワークミーティングから生じました。 添付書類はNCPを書くことができるくらいの情報を含んでいません、そして、私はそれほどまもなく、別のメモを出すつもりです。 このメモへの応答はNWG/RFCか個人的な注意として私に請求されます。

                     HOST-HOST Communication Protocol
                           in the ARPA Network*

アーパネット*のホスト兼ホスト通信プロトコル

   by C. Stephen Carr
   University of Utah
   Salt Lake City, Utah

C.スティーブン・カー・ユタ大学ソルトレイクシティー(ユタ)のそばで

   and

そして

   by Stephen D. Crocker
   University of California
   Los Angeles, California

スティーブンD.医者カリフォルニア大学ロサンゼルス校、カリフォルニアのそばで

   and

そして

   by Vinton G. Cerf
   University of California
   Los Angeles, California

ビントンG.サーフカリフォルニア大学ロサンゼルス校、カリフォルニアのそばで

   *This research was sponsored by the Advanced Research Projects
   Agency, Department of Defense, under contracts AF30(602)-4277 and
   DAHC15-69-C-0825.

*この研究はAdvanced Research Projects Agency、契約法AF30(602)-4277とDAHC15 69C0825の下の国防総省によって後援されました。

INTRODUCTION

序論

   The Advanced Research Projects Agency (ARPA) Computer Network
   (hereafter referred to as the "ARPA network") is one of the most
   ambitious computer networks attempted to date.  [1]  The types of

Advanced Research Projects Agency(ARPA)コンピュータNetwork(今後「ARPAネットワーク」と呼ばれる)はこれまで試みられた中で最も野心満々のコンピュータネットワークの1つです。 [1] タイプ

Crocker, et. al.                                                [Page 1]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [1ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

   machines and operating systems involved in the network vary widely.
   For example, the computers at the first four sites are an XDS 940
   (Stanford Research Institute), an IBM 360/75 (University of
   California, Santa Barbara), an XDS SIGMA-7 (University of California,
   Los Angeles), and a DEC PDP-10 (University of Utah).  The only
   commonality among the network membership is the use of highly
   interactive time-sharing systems; but, of course, these are all
   different in external appearance and implementation.  Furthermore, no
   one node is in control of the network.  This has insured reliability
   but complicates the software.

ネットワークにかかわるマシンとオペレーティングシステムはばらつきが大きいです。 例えば、最初の4つのサイトのコンピュータは、XDS940(スタンフォード研究所)と、IBM360/75(カリフォルニア大学、サンタバーバラ)と、XDS SIGMA-7(カリフォルニア大学ロサンゼルス校)と、DEC PDP-10(ユタ大学)です。 ネットワーク会員資格の中の唯一の共通点が非常に対話的な時分割システムの使用です。 もちろん、しかし、これらは外部の外観と実装においてすべて異なっています。 その上、いいえ1、ノードはネットワークのコントロール中です。 これは、信頼性に保険をかけますが、ソフトウェアを複雑にします。

   Of the networks which have reached the operational phase and been
   reported in the literature, none have involved the variety of
   computers and operating systems found in the ARPA network.  For
   example, the Carnegie-Mellon, Princeton, IBM network consists of
   360/67's with identical software. [2]  Load sharing among identical
   batch machines was commonplace at North American Rockwell Corporation
   in the early 1960's.  Therefore, the implementers of the present
   network have been only slightly influenced by earlier network
   attempts.

操作上のフェーズに達して、文学で報告されたネットワークでは、なにもARPAネットワークで見つけられたコンピュータとオペレーティングシステムのバラエティーにかかわっていません。 カーネギー-メロン、プリンストン、例えば、IBMネットワークは同じソフトウェアで360/67から成ります。 [2] 同じバッチマシンの中の負荷分割法は1960年代前半の北米のロックウェル社で平凡でした。 したがって、以前のネットワーク試みで現在のネットワークのimplementersはわずかに影響を及ぼされるだけでした。

   However, early time-sharing studies at the University of California
   at Berkeley, MIT, Lincoln Laboratory, and System Development
   Corporation (all ARPAA sponsored) have had considerable influence on
   the design of the network.  In some sense, the ARPA network of time-
   shared computers is a natural extension of earlier time-sharing
   concepts.

しかしながら、カリフォルニア大学バークレイ校、MIT、リンカーン研究所、およびシステム開発社(ARPAAが後援したすべて)での早めの時分割研究はネットワークのデザインに非常に大きな影響力を持っていました。 何らかの意味で、時間の共有されたコンピュータのARPAネットワークは前に概念を時分割する自然な拡大です。

   The network is seen as a set of data entry and exit points into which
   individual computers insert messages destined for another (or the
   same) computer, and from which such messages emerge.  The format of
   such messages and the operation of the network was specified by the
   network contractor (BB&N) and it became the responsibility of
   representatives of the various computer sites to impose such
   additional constraints and provide such protocol as necessary for
   users at one site to use resources at foreign sites.  This paper
   details the decisions that have been made and the considerations
   behind these decisions.

ネットワークは個々のコンピュータが別の(または、同じくらい)コンピュータのために運命づけられたメッセージを挿入して、そのようなメッセージが出て来る1セットのデータエントリーとエキジットポイントと考えられます。 そのようなメッセージの形式とネットワークの操作はネットワーク契約者(掲示板とN)によって指定されました、そして、1つのサイトのユーザが外国サイトでリソースを使用するのは様々なコンピュータサイトの代表がそのような追加規制を課して、必要であるようなプロトコルを提供する責任になりました。 この論文はこれらの決定の後ろでされた決定と問題を詳しく述べます。

   Several people deserve acknowledgement in this effort.  J. Rulifson
   and W. Duvall of SRI participated in the early design effort of the
   protocol and in the discussions of NIL.  G. Deloche of Thompson-CSF
   participated in the design effort while he was at UCLA and provided
   considerable documentation.  J. Curry of Utah and P. Rovner of
   Lincoln Laboratory reviewed the early design and NIL.  W. Crowther of
   Bolt, Beranek and Newman, contributed the idea of a virtual net.  The
   BB&N staff provided substantial assistance and guidance while
   delivering the network.

数人はこの取り組みにおける承認に値します。 J。 SRIのRulifsonとW.デュヴァルはプロトコルの早めのデザイン取り組みとNILの議論に参加しました。 G。 彼は、UCLAにいて、かなりのドキュメンテーションを提供しましたが、トンプソン-CSFのDelocheはデザイン取り組みに参加しました。 J。 ユタのカレーとリンカーン研究所のP.Rovnerは早めのデザインとNILを見直しました。 W。 Boltのクラウザー(Beranekとニューマン)は、仮想のネットの考えを寄付しました。 掲示板とNスタッフはネットワークを提供している間、かなりの支援と指導を提供しました。

Crocker, et. al.                                                [Page 2]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [2ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

   We have found that, in the process of connecting machines and
   operating systems together, a great deal of rapport has been
   established between personnel at the various network node sites.  The
   resulting mixture of ideas, discussions, disagreements, and
   resolutions has been highly refreshing and beneficial to all
   involved, and we regard the human interaction as a valuable by-
   product of the main effect.

私たちは、マシンとオペレーティングシステムを一緒に接続することの途中に大きな関係が様々なネットワーク・ノードサイトの人員の間で確立されたのがわかりました。 考え、議論、不一致、および解決の結果として起こる混合物は、かかわるすべてに、非常にすっきりであって有益です、そして、私たちはaとしての貴重な人間の交流を見なします。主効果の生成物。

THE NETWORK AS SEEN BY THE HOSTS

ホストによって見られるネットワーク

   Before going on to discuss operating system communication protocol,
   some definitions are needed.

オペレーティングシステム通信プロトコルについて議論し続ける前に、いくつかの定義が必要です。

      A HOST is a computer system which is a part of the network,

HOSTはネットワークの一部であるコンピュータ・システムです。

      An IMP (Interface Message Processor) is a Honeywell DDP-516
      computer which interfaces with up to four HOSTs at a particular
      site, and allows HOSTs access into the network.  The configuration
      of the initial four-HOST network is given in figure 1.  The IMPs
      from a store-and-forward communications network.  A companion
      paper in these proceedings covers the IMPs in some detail. [3]

IMP(インタフェースMessage Processor)は特定のサイトの最大4HOSTsに連結して、ネットワークへのアクセスをHOSTsに許すハネウェルDDP-516コンピュータです。 図1で初期の4HOSTのネットワークの構成を与えます。 店とフォワード通信網からのIMPs。 これらの議事における仲間論文は何らかの詳細にIMPsをカバーしています。 [3]

   A message is a bit stream less than 8096 bits long which is given to
   an IMP by a HOST for transmission to another HOST.  The first 32 bits
   of the message are the leader.  The leader contains the following
   information:

メッセージは長い間少し8096ビット未満流れることです(別のHOSTへの伝送のためHOSTによってIMPに与えられています)。メッセージの最初の32ビットはリーダーです。 リーダーは以下の情報を含みます:

      (a) HOST
      (b) Message Type
      (c) Flags
      (d) Link Number

(a) ホスト(b)メッセージタイプ(c)旗(d)リンク番号

   When a message is transmitted from a HOST to its IMP, the HOST field
   of the leader names the receiving HOST.  When the message arrives at
   the receiving HOST, the HOST field names the sending HOST.

メッセージがいつか、メッセージが受信HOST、HOSTフィールド名に到着するとき、HOSTからIMP(リーダーの分野が受信HOSTを命名するHOST)まで伝えられる、発信しているHOST。

   Only two message types are of concern in this paper.  Regular
   messages are generated by a HOST and sent to its IMP for transmission
   to a foreign HOST.  The other message type of interest is a RFNM
   (Request-for-Next-Message).  RFNM's are explained in conjunction with
   links.

2つのメッセージタイプだけがこの紙で重要です。 外国HOSTへの伝送のため通常のメッセージをHOSTは生成して、IMPに送ります。興味があるもう片方のメッセージタイプはRFNM(次のメッセージのために、要求する)です。 RFNMのものはリンクに関連して説明されます。

   The flag field of the leader controls special cases not of concern
   here.

リーダーの旗の分野はここで重要でない特別なケースを制御します。

Crocker, et. al.                                                [Page 3]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [3ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

   The link number identifies over which of 256 logical paths (links)
   between the sending HOST and the receiving HOST the message will be
   sent.  Each link is unidirectional and is controlled by the network
   so that no more than one message at a time may be sent over it.  This
   control is implemented using RFNM messages.  After a sending HOST has
   sent a message to a receiving HOST over a particular link, the
   sending HOST is prohibited from sending another message over that
   same link until the sending HOST receives a RFMN.  The RFNM is
   generated by the IMP connected to the receiving HOST, and the RFNM is
   sent back to the sending HOST after the message has entered the
   receiving HOST.  It is important to remember that there are 356 links
   in each direction and that no relationship among these is imposed by
   the network.

リンク番号は、メッセージが発信しているHOSTと受信HOSTの間の256の論理パス(リンク)のどれの上に送られるかを特定します。 各リンクは、単方向であり、一度に1つ未満のメッセージをそれの上に送ることができるようにネットワークによって制御されます。 この管理は、RFNMメッセージを使用することで実施されます。 送付HOSTが特定のリンクの上の受信HOSTにメッセージを送った後に、発信しているHOSTは発信しているHOSTがRFMNを受けるまでその同じリンクの上に別のメッセージを送るのが禁止されます。 RFNMは受信HOSTに接続されたIMPによって生成されます、そして、メッセージが受信HOSTに入った後に発信しているHOSTはRFNMに送り返されます。各方向には356個のリンクがあって、これらの中の関係が全くネットワークによって課されないのを覚えているのが重要です。

   The purpose of the link and RFMN mechanism is to prohibit individual
   users from overloading an IMP or a HOST.  Implicit in this purpose is
   the assumption that a user does not use multiple links to achieve a
   wide band, and to a large extent the HOST-HOST protocol cooperates
   with this assumption.  An even more basic assumption, of course, is
   that the network's load comes from some users transmitting sequences
   of messages rather than many users transmitting single messages
   coincidently.

リンクとRFMNメカニズムの目的はIMPかHOSTを積みすぎるのから個々のユーザを禁じることです。この目的で暗黙であることは、ユーザが広いバンドを達成するのに複数のリンクを使用しないで、この仮定にHOST-HOSTが議定書を作るという大きい程度まで協力するという仮定です。 さらに基本的な仮定はもちろんネットワークの負荷が単一のメッセージコインシデンスを伝える多くのユーザよりむしろメッセージの系列を伝える何人かのユーザから来るということです。

   In order to delimit the length of the message, and to make it easier
   for HOSTs of differing word lengths to communicate, the following
   formatting procedure is used.  When a HOST prepares a message for
   output, it creates a 32-bit leader.  Following the leader is a binary
   string, called marking, consisting of an arbitrary number of zeros,
   followed by one.  Marking makes is possible for the sending HOST to
   synchronize the beginning of the text message with its word
   boundaries.  When the last bit of a message has entered an IMP, the
   hardware interface between the IMP and HOST appends a one followed by
   enough zeros to make the message length a multiple of 16 bits.  These
   appended bits are called padding.  Except for the marking and
   padding, no limitations are placed on the text of a message.  Figure
   2 shows a typical message sent by a 24-bit machine.

メッセージの長さを区切って、異なった語長のHOSTsが交信するのをより簡単にするように、以下の形式手順は使用されています。 HOSTが出力のためにメッセージを準備するとき、それは32ビットのリーダーを創造します。 リーダーに続くのは、マークと呼ばれる1つがあとに続いたゼロの特殊活字の数字から成る2進のストリングです。 発信しているHOSTがテキストメッセージの始まりを語境界と同時にさせるのにおいて造をマークするのは可能です。 メッセージの最後のビットがIMPに入ったとき、IMPとHOSTとのハードウェア・インタフェースは1つを追加します、続いて、メッセージ長を16ビットの倍数にすることができるくらいのゼロを追加します。 これらの追加されたビットは詰め物と呼ばれます。 マークと詰め物以外に、制限は全くメッセージのテキストに置かれません。 図2は24ビットのマシンによって送られた典型的なメッセージを示しています。

DESIGN CONCEPTS

設計思想

   The computers participating in the network are alike in two important
   respects: each supports research independent of the network, and each
   is under the discipline of a time-sharing system.  These facts
   contributed to the following design philosophy.

ネットワークに参加するコンピュータは2つの重要な点で似ています: それぞれがネットワークの如何にかかわらず研究をサポートします、そして、それぞれが時分割システムの規律の下にあります。 これらの事実は以下の設計理念に貢献しました。

   First, because the computers in the network have independent purposes
   it is necessary to preserve decentralized administrative control of
   the various computers.  Since all of the time-sharing supervisors
   possess elaborate and definite accounting and resource allocation

ネットワークにおけるコンピュータには独立している目的があるので、まず最初に、様々なコンピュータの分散運営管理コントロールを保持するのが必要です。 時分割監督には皆、入念で明確な会計と資源配分があるので

Crocker, et. al.                                                [Page 4]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [4ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

   mechanisms, we arranged matters so that these mechanisms would
   control the load due to the network in the same way that they control
   locally generated load.

メカニズム、私たちが繰り合わせたので、これらのメカニズムがネットワークのためそれらが局所的に制御するのと同じように負荷を制御するだろうというのが負荷を生成しました。

   Second, because the computers are all operated under time-sharing
   disciplines, it seemed desirable to facilitate basic interactive
   mechanisms.

2番目に、コンピュータが時分割規律の下ですべて操作されるので、基本的な対話的なメカニズムを容易にするのは望ましく思えました。

   Third, because this network is used by experienced programmers it was
   imperative to provide the widest latitude in using the network.
   Restrictions concerning character sets, programming languages, etc.
   would not be tolerated and we avoided such restrictions.

3番目に、このネットワークが経験豊富なプログラマによって使用されるので、ネットワークを使用するのにおいて最も広い緯度を提供するのは必須でした。 文字集合に関する制限、プログラミング言語などは許容されなかったでしょう、そして、私たちはそのような制限を避けました。

   Fourth, again because the network is used by experienced programmers,
   it was felt necessary to leave the design open-ended.  We expect that
   conventions will arise from time to time as experience is gained, but
   we felt constrained not to impose them arbitrarily.

4番目に、ネットワークが再び経験豊富なプログラマによって使用されるので、デザインを制限のない状態でおくのは必要であると感じられました。 経験するのに従って、コンベンションが時々起こると予想しますが、私たちは、任意にそれらを課さないようにやむを得ないと思いました。

   Fifth, in order to make network participation comfortable, or in some
   cases, feasible, the software interface to the network should require
   minimal surgery on the HOST operating system.

5番目に、ネットワーク参加を快適にするか、またはいくつかの場合で可能です、ネットワークへのソフトウェア・インタフェースはHOSTオペレーティングシステムで最小量の外科を必要とするべきです。

   Finally, we except the assumption stated above that network use
   consists of prolonged conversations instead of one-shot requests.

最終的に、仮定以外の私たちは、上にネットワーク使用が1回限りの要求の代わりに長引いている会話から成ると述べました。

   These considerations led to the notions of connections, a Network
   Control Program, a control link, control commands, sockets, and
   virtual nets.

これらの問題は接続、Network Control Program、コントロールリンク、制御コマンド、ソケット、および仮想のネットの概念につながりました。

   A connection is an extension of a link.  A connection connects two
   processes so that output from one process is input to the other.
   Connections are simplex, so two connections are needed if two
   processes are to converse in both directions.

接続はリンクの拡大です。 接続は、1つのプロセスからの出力がもう片方に入力されるように、2つのプロセスを接続します。 コネクションズがシンプレクスであるので、2つのプロセスが両方の方向に話すつもりであるなら、2つの接続が必要です。

   Processes within a HOST communicate with the network through a
   Network Control Program (NCP).  In most HOSTs, the NCP will be a part
   of the executive, so that processes will use system calls to
   communicate with it.  The primary function of the NCP is to establish
   connections, break connections, switch connections, and control flow.

HOSTの中のプロセスはNetwork Control Program(NCP)を通してネットワークとコミュニケートします。 ほとんどのHOSTsでは、NCPは幹部社員の一部になるでしょう、プロセスがそれで交信するのにシステムコールを使用するように。 NCPのプライマリ機能は接続、中断接続、スイッチ接続、およびコントロール流動を確立することです。

   In order to accomplish its tasks, a NCP in one HOST must communicate
   with a NCP in another HOST.  To this end, a particular link between
   each pair of HOSTs has been designated as the control link.  Messages
   received over the control link are always interpreted by the NCP as a
   sequence of one or more control commands.  As an example, one of the
   kinds of control commands is used to assign a link and initiate a

タスクを達成するために、1HOSTのNCPは別のHOSTのNCPで交信しなければなりません。このために、各組のHOSTsの間の特定のリンクはコントロールリンクとして指定されました。 1つ以上のコントロールの系列が命令するようにコントロールリンクの上に受け取られたメッセージはいつもNCPによって解釈されます。 例として、制御コマンドの種類の1つは、リンクを割り当てて、aを開始するのに使用されます。

Crocker, et. al.                                                [Page 5]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [5ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

   connection, while another kind carries notification that a connection
   has been terminated.  A partial sketch of the syntax and semantics of
   control commands is given in the next section.

もう1種類が接続が終えられたという通知を運ぶ間の接続。 次のセクションで構文の部分的なスケッチと制御コマンドの意味論を与えます。

   A major issue is how to refer to processes in a foreign HOST.  Each
   HOST has some internal naming scheme, but these various schemes often
   are incompatible.  Since it is not practical to impose a common
   internal process naming scheme, an intermediate name space was
   created with a separate portion of the name space given to each HOST.
   It is left to each HOST to map internal process identifiers into its
   name space.

主要な問題はどのようにプロセスについて言及するかという外国HOSTのことです。各HOSTには、何らかの内部の命名体系がありますが、これらの様々な体系はしばしば両立しないです。 一般的な内部のプロセス命名体系を課すのが実用的でないので、中間的名前スペースはスペースという名前の別々の部分を各HOSTに与えていて作成されました。それが内部のプロセス識別子を名前スペースに写像するのが各HOSTに残されます。

   The elements of the name space are called sockets.  A socket forms
   one end of a connection, and a connection is fully specified by a
   pair of sockets.  A socket is specified by the concatenation of three
   numbers:

スペースという名前の原理はソケットと呼ばれます。 ソケットは接続の片端を形成します、そして、接続は1組のソケットによって完全に指定されます。 ソケットは3つの番号の連結で指定されます:

      (a) a user number (24 bits)
      (b) a HOST number (8 bits)
      (c) AEN (8 bits)

(b) (a) ユーザ番号(24ビット)はHOST番号(8ビット)(c)AENです。(8ビット)

   A typical socket is illustrated in Figure 3.

典型的なソケットは図3で例証されます。

   Each HOST is assigned all sockets in the name space which have field
   (b) equal to the HOST's own identification.

スペースという名前のHOSTの自己の識別と等しい分野(b)を持っているすべてのソケットが各HOSTに割り当てられます。

   A socket is either a receive socket or a send socket, and is so
   marked by the lower-order bit of the AEN (0 = receive, 1 = send).
   The other seven bits of the AEN simply provide a sizable population
   of sockets for each used number at each HOST.  (AEN stands for
   "another eight-bit number")

ソケットは、aがソケットを受けるか、またはaがソケットを送るということであり、AENの下層階級ビットによって非常にマークされます(=が受け取る0、1=は発信します)。 AENの他の7ビットは単に各HOSTのそれぞれの中古の数にソケットのかなり大きい人口を提供します。(「もう1つの8ビットの数」のためのAENスタンド)

   Each user is assigned a 24-bit user number which uniquely identifies
   him throughout the network.  Generally this will be the 8-bit HOST
   number of his home HOST, followed by 16 bits which uniquely identify
   him at that HOST.  Provision can also be made for a user to have a
   user number not keyed to a particular HOST, an arrangement desirable
   for mobile users who might have no home HOST or more than one home
   HOST.  This 24-bit user number is then used in the following manner.
   When a user signs onto a HOST, his user number is looked up.
   Thereafter, each process the user creates is tagged with his user
   number.  When the user signs onto a foreign HOST via the network, his
   same user number is used to tag processes he creates in that HOST.
   The foreign HOST obtains the user number either by consulting a table
   at login time, as the home HOST does, or by noticing the
   identification of the caller.  The effect of propagating the user's
   number is that each user creates his own virtual net consisting of
   processes he has created.  This virtual net may span an arbitrary

ネットワーク中で唯一彼を特定する24ビットのユーザ番号は各ユーザに割り当てられます。 一般にこれはそのHOSTで唯一彼を特定する16ビットが支えた彼のホームHOSTの8ビットのHOST番号になるでしょう。また、ユーザには特定のHOSTに合わせられなかったユーザ番号があるのを設備をすることができます、ホームHOSTか1つ以上のホームのHOSTを全く持っていないかもしれないモバイルユーザにとって、望ましいアレンジメント。次に、この24ビットのユーザ番号は以下の方法で使用されます。 ユーザがHOSTに署名するとき、彼のユーザ番号は調べられます。 その後、彼のユーザ番号でユーザが作成する各プロセスはタグ付けをされます。 ユーザがネットワークを通して外国HOSTに署名するとき、彼の同じユーザ番号は、彼がそのHOSTで作成するプロセスにタグ付けをするのに使用されます。外国HOSTは、ログイン時にHOSTがするホームとしてテーブルに相談するか、または訪問者の識別に気付くことによって、ユーザ番号を得ます。 ユーザの番号を伝播するという効果は各ユーザが彼が作成したプロセスの彼自身の仮想のネットの成ることを作成するということです。 この仮想のネットがわたるかもしれない、任意

Crocker, et. al.                                                [Page 6]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [6ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

   number of HOSTs.  It will thus be easy for a user to connect his
   processes in arbitrary ways, while still permitting him to connect
   his processes with those in other virtual nets.

HOSTsの数。 その結果、彼が他の仮想のネットにおけるそれらにプロセスを接続することをまだ許可している間、ユーザが任意の方法で彼のプロセスを接続するのは、簡単でしょう。

   The relationship between sockets and processes is now describable
   (see Figure 4).  For each user number at each HOST, there are 128
   send sockets and 128 receive sockets.  A process may request from the
   local NCP the use of any one of the sockets with the same user
   number; the request is granted if the socket is not otherwise in use.
   The key observation here is that a socket requested by a process
   cannot already be in use unless it is by some other process within
   the same virtual net, and such a process is controlled by the same
   user.

ソケットとプロセスとの関係は現在、説明可能です(図4を見てください)。 それぞれでHOSTに付番して、いる各ユーザに関しては、128はソケットを送ります、そして、128はソケットを受けます。 プロセスはローカルのNCPから同じユーザ番号でソケットのどれかの使用を要求するかもしれません。 そうでなければ、ソケットが使用中でないなら、要求は承諾されます。 同じ仮想のネットの中にそれがある他のプロセスでない場合プロセスによって要求されたソケットが既に使用中であるはずがなく、そのようなプロセスが同じユーザによって制御されるという主要な観測は、ここにあります。

   An unusual aspect of the HOST-HOST protocol is that a process may
   switch its end of a connection from one socket to another.  The new
   socket may be in any virtual net and at any HOST, and the process may
   initiate a switch either at the time the connection is being
   established, or later.  The most general forms of switching entail
   quite complex implementation, and are not germane to the rest of this
   paper, so only a limited form will be explained.  This limited form
   of switching provides only that a process may substitute one socket
   for another while establishing a connection.  The new socket must
   have the same user number and HOST number, and the connection is
   still established to the same process.  This form of switching is
   thus only a way of relabelling a socket, for no charge in the routing
   of messages takes place.  In the next section we document the system
   calls and control commands; in the section after next, we consider
   how login might be implemented.

HOST-HOSTプロトコルの珍しい局面はプロセスが1個のソケットから別のソケットまでの接続の終わりを切り換えるかもしれないということです。 どんな仮想のネットとどんなHOSTにも新しいソケットがあるかもしれなくて、接続が確立しているか、または、より遅いときに、プロセスはスイッチを開始するかもしれません。 切り換えの最も一般的なフォームがかなり複雑な実装を伴って、この紙の残りに適切でないので、限局型だけが説明されるでしょう。 この限局型の切り換えは、プロセスが取引関係を築いている間1個のソケットしか別のものの代わりに用いないかもしれないのを前提とします。 新しいソケットには、同じユーザ番号とHOST番号がなければなりません、そして、接続はまだ同じプロセスに確立されています。 その結果、このフォームの切り換えはソケットを再ラベルする方法にすぎません、メッセージのルーティングにおける充電が全く行われないので。 次のセクションで、私たちはシステムコールと制御コマンドを記録します。 次に後のセクションでは、私たちは、ログインがどのように実装されるかもしれないかを考えます。

SYSTEM CALLS AND CONTROL COMMANDS

システムコールと制御コマンド

   Here we sketch the mechanisms of establishing, switching and breaking
   a connection.  As noted above, the NCP interacts with user processes
   via system calls and with other NCPs via control commands.  We
   therefore begin with a partial description of system calls and
   control commands.

ここに、私たちは接続を確立して、切り換えて、調教するメカニズムについてスケッチします。 上で述べたように、NCPはシステムコールを通して他のNCPで制御コマンドでユーザ・プロセスと対話します。 したがって、私たちはシステムコールと制御コマンドの部分的な記述で始めます。

   System calls will vary from one operating system to another, so the
   following description is only suggestive.  We assume here that a
   process has several input-output paths which we will call ports.
   Each port may be connected to a sequential I/O device, and while
   connected, transmits information in only one direction.  We further
   assume that the process is blocked (dismissed, slept) while
   transmission proceeds.  The following is the list of system calls:

システムコールが1台のオペレーティングシステムから別のものに異なるので、以下の記述は思わせ振りであるだけです。 私たちは、ここでプロセスには私たちがポートと呼ぶつもりであるいくつかの入出力経路があると思います。 各ポートが連続した入出力デバイスにつなげられるかもしれない、ゆったり過ごす、一方向だけに接続して、情報を伝えます。 私たちが、プロセスが妨げられるとさらに思う、(棄却されて、眠る、)、トランスミッションは続きますが。 ↓これはシステムコールのリストです:

Crocker, et. al.                                                [Page 7]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [7ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

            Init      <port>, <AEN 1>, <AEN 2>, <foreign socket>

イニット<ポート>、<AEN1>、<AEN2>、<の外国ソケット>。

      where <port> is part of the process issuing the Init
                     _
            <AEN 1>   |
      and             +- are 8-bit AEN's (see Figure 2)
            <AEN 2>   |
                     _|

<ポート>がInit_<AEN1>を発行するプロセスの一部であるところ| そして、+は8ビットのAEN(図2を見る)の<AEN2>です。| _|

            The first AEN is used to initiate the connection; the second
            is used while the connection exists.

最初のAENは接続を開始するのに使用されます。 接続は存在していますが、2番目は使用されています。

            <foreign socket> is the 40-bit socket name of the distant
            end of the connection.

<の外国ソケット>は接続の遠い終わりの40ビットのソケット名です。

            The lower-order bits of <AEN 1> and <AEN 2> must agree, and
            these must be the complement of the lower-order bit of
            <foreign socket>.

<AEN1>と<AEN2>の下層階級ビットは同意しなければなりません、そして、これらは<の外国ソケット>の下層階級ビットの補数であるに違いありません。

            The NCP concatenates <AEN 1> and <AEN 2> each with the user
            number of the process and the HOST number to form 40-bit
            sockets.  It then sends a Request for Connection (RFC)
            control command to the distant NCP.  When the distant NCP
            responds positively, the connection is established and the
            process is unblocked.  If the distant NCP responds
            negatively, the local NCP unblocks the requesting process,
            but informs it that the system call has failed.

NCPはプロセスのユーザ番号と40ビットのソケットを形成するHOST番号でそれぞれ<AEN1>と<AEN2>を連結します。 そして、それはConnection(RFC)のためのRequestに遠方のNCPへの制御コマンドを送ります。 遠方のNCPが積極的に対応するとき、接続は確立されます、そして、プロセスは「非-妨げ」られます。 遠方のNCPが否定的に応じるなら、ローカルのNCPは、要求プロセスを「非-妨げ」ますが、システムコールが失敗したことをそれに知らせます。

            Listen <port>, <AEN 1>

<ポート>、<AEN1>を聴いてください。

      where <port> and <AEN 1> are as above.  The NCP retains the ports
            and <AEN 1> and blocks the process.  When an RFC control
            command arrives naming the local socket, the process is
            unblocked and notified that a foreign process is calling.

<ポート>と<AEN1>が同じくらい上にあるところ。 NCPは、ポートと<AEN1>を保有して、プロセスを妨げます。 RFC制御コマンドが地方のソケットを命名しながら到着するとき、プロセスは、外国プロセスが呼んでいるように「非-妨げ」られて、通知されます。

            Accept <AEN 2>

<AEN2>を受け入れてください。

            After a Listen has been satisfied, the process may either
            refuse the call or accept it and switch it to another
            socket.  To accept the call, the process issues the Accept
            system call.  The NCP then sends back an RFC control
            command.

Listenが満足した後に、プロセスは、別のソケットに呼び出しを拒否するか、それを受け入れて、またはそれを切り換えるかもしれません。 呼び出しを受け入れるために、プロセスはAcceptシステムコールを発行します。 そして、NCPはRFC制御コマンドを返送します。

            Close <port>

<ポート>を閉じてください。

            After establishing a connection, a process issues a Close to
            break the connection.  The Close is also issued after a
            Listen to refuse a call.

取引関係を築いた後に、プロセスは、電話を切るためにCloseを発行します。 また、Closeは、Listenの後に呼び出しを拒否するために発行されます。

Crocker, et. al.                                                [Page 8]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [8ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

            Transmit <port>, <addr>

<ポート>、<addr>を伝えてください。

            If <port> is attached to a send socket, <addr> points to a
            message to be sent.  This message is preceded by its length
            in bits.

<ポート>がaに取り付けられるなら、ソケットを送ってください、そして、<addr>は送られるべきメッセージを示します。 ビットの長さはこのメッセージに先行します。

            If <port> is attached to a receive socket, a message is
            stored at <addr>.  The length of the message is stored
            first.

<ポート>がaに取り付けられるなら、ソケットを受けてください、そして、メッセージは<addr>に保存されます。 メッセージの長さは最初に、保存されます。

Control Commands

制御コマンド

   A vocabulary of control commands has been defined for communication
   between Network Control Programs.  Each control command consists of
   an 8-bit operation code to indicate its function, followed by some
   parameters.  The number and format of parameters is fixed for each
   operation code.  A sequence of control commands destined for a
   particular HOST can be packed into a single control message.

制御コマンドのボキャブラリーはNetwork Control Programsのコミュニケーションのために定義されました。各制御コマンドは、いくつかのパラメタがあとに続いた機能を示すために8ビット演算のコードから成ります。 パラメタの数と形式は各命令コードのために固定されています。 特定のHOSTのために運命づけられた制御コマンドの系列に単一管理メッセージに詰め込むことができます。

      RFC   <my socket 1>, <my socket 2>.

RFC<、私のソケット1>、<、私のソケット2>。

            <your socket>, (<link>)

<、あなたのソケット>。(<リンク>)

   This command is sent because a process has executed either an Init
   system call or an Accept system call.  A link is assigned by the
   prospective receiver, so it is omitted if <my socket 1> is a send
   socket.

プロセスがInitシステムコールかAcceptシステムコールのどちらかを実行したので、このコマンドを送ります。 <であるなら省略されて、私のソケット1>がaであることでありリンクが将来の受信機によって割り当てられるAはソケットを送ります。

   There is distinct advantage in using the same commands both to
   initiate a connection (Init) and to accept a call (Accept).  If the
   responding command were different from the initiating command, then
   two processes could call each other and become blocked waiting for
   each other to respond.  With this scheme, no deadlock occurs and it
   provides a more compact way to connect a set of processes.

ともに、接続(イニット)を開始して、呼び出しを受け入れる同じコマンドを使用するのにおいて異なった利点があります(受け入れてください)。 応じるコマンドが開始コマンドと異なるなら、互いが応じるのを待ちながら、2つのプロセスが、互いと呼んで、妨げられるようになることができるでしょうに。 この体系で、行き詰まりは全く起こりません、そして、それは1セットのプロセスを接続するよりコンパクトな方法を提供します。

      CLS      <my socket>, <your socket>

CLS<、私のソケット>、<、あなたのソケット>。

   The specified connection is terminated

指定された接続は終えられます。

      CEASE    <link>

<リンク>をやめてください。

   When the receiving process does not consume its input as fast as it
   arrives, the buffer space in the receiving HOST is used to queue the
   waiting messages.  Since only limited space is generally available,
   the receiving HOST may need to inhibit the sending HOST from sending
   any more messages over the offending connection.  When the sending
   HOST receives this command, it may block the process generating the
   messages.

受信プロセスが到着するほど速く入力を消費しないとき、受信HOSTのバッファ領域は、待ちメッセージを列に並ばせるのに使用されます。 限られたスペースだけが一般に利用可能であるので、受信HOSTは、発信しているHOSTが怒っている接続の上にそれ以上のメッセージを送るのを禁止する必要があるかもしれません。 発信しているHOSTがこのコマンドを受け取るとき、それはメッセージを生成するプロセスを妨げるかもしれません。

Crocker, et. al.                                                [Page 9]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [9ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

      RESUME   <link>

<リンク>を再開してください。

   This command is also sent from the receiving HOST to the sending HOST
   and negates a previous CEASE.

このコマンドは、また、受信HOSTから発信しているHOSTに送られて、前のCEASEを否定します。

LOGGING IN

ログインします。

   We assume that within each HOST there is always a process in
   execution which listens to login requests.  We call this process the
   logger, and it is part of a special virtual net whose user number is
   zero.  The logger is programmed to listen to calls on socket number
   0.  Upon receiving a call, the logger switches it to a higher (even)
   numbered sockets, and returns a call to the socket numbered one less
   than the send socket originally calling.  In this fashion, the logger
   can initiate 127 conversations.

私たちは、そこの各HOSTの中のそれがログイン要求を聞く実行でいつもプロセスであると思います。 私たちは、このプロセスをきこりと呼びます、そして、それはユーザ番号がゼロである特別な仮想のネットの一部です。 きこりがソケットNo.0で呼び出しを聞くようにプログラムされます。 呼び出しを受けるとききこりが、より高い)さえ番号付のソケットにそれを切り換えて、ソケットそれほど番号付のものに訪問を返す、元々、ソケットを呼ばせてください。 こんなやり方で、きこりは127の会話を開始できます。

   To illustrate, assume a user whose identification is X'010005' (user
   number 5 at UCLA) signs into UCLA, starts up one of his programs, and
   this program wants to start a process at SRI.  No process except the
   logger is currently willing to listen to our user, so he executes

例証するために、識別がUCLAへのX'010005'(UCLAのユーザNo.5)サイン、彼のプログラムの1つへの始めであるユーザを思ってください。そうすれば、このプログラムはSRIでプロセスを始めたがっています。 きこり以外のどんなプロセスも、現在、私たちのユーザ、彼が実行するそうを聞いても構わないと思っていません。

         Init, <port> = 1, <AEN 1> = 7, <AEN 2> = 7,

イニット、<ポート>=1、<AEN1>=7、<AEN2>=7

               <foreign socket> = 0

<の外国ソケット>=0

   His process is blocked, and the NCP at UCLA sends

彼のプロセスは妨げられます、そして、UCLAのNCPは発信します。

         RFC   <my socket 1> = X'0100050107',

RFC<、私のソケット1>はX'0100050107'と等しいです。

               <my socket 2> = X'0100050107',

<、私のソケット2>はX'0100050107'と等しいです。

               <your socket> = X'000000200'

<はあなたのソケット>=X'000000200'です。

   The logger at SRI is notified when this message is received, because
   it has previously executed

以前に実行されていた状態で通知されたので、このメッセージが受信されているとき、SRIのきこりは通知されます。

         Listen   <port> = 9, <AEN 1> = 0.

<ポート>=9、<AEN1>=0を聴いてください。

   The logger then executes

その時が処刑するきこり

         Accept   <AEN 2> = 88.

<AEN2>=88を受け入れてください。

Crocker, et. al.                                               [Page 10]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [10ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

   In response to the Accept, the SRI NCP sends

Acceptに対応して、SRI NCPは発信します。

         RFC   <my socket 1> = X'0000000200'

RFC<は私のソケット1>=X'0000000200'です。

               <my socket 2> = X'0000000258'

<は私のソケット2>=X'0000000258'です。

               <your socket> = X'0100050107'

<はあなたのソケット>=X'0100050107'です。

               <link> = 37

<リンク>=37

   where the link has been chosen from the set of available links.  The
   SRI logger than executes

リンクが利用可能なリンクのセットから選ばれたところ。 SRIきこり、実行

         Init     <port> = 10

イニット<ポート>=10

               <AEN 1> = 89, <AEN 2> = 89,

<AEN1>は89、<AEN2>=89と等しいです。

               <foreign socket> = X'0100050106'

<の外国ソケット>はX'0100050106'と等しいです。

   which causes the NCP to send

どれで、NCPは発信しますか。

         RFC   <my socket 1> = X'0000000259'

RFC<は私のソケット1>=X'0000000259'です。

               <my socket 2> = x'0000000259'

<は私のソケット2>=x'0000000259'です。

               <your socket> = X'0100050106'

<はあなたのソケット>=X'0100050106'です。

   The process at UCLA is unblocked and notified of the successful Init.
   Because SRI logger always initiates a connection to the AEN one less
   than it has just been connected to, the UCLA process then executes

UCLAのプロセスは、うまくいっているInitについて「非-妨げ」られて、通知されます。 SRIきこりがいつも次にUCLAプロセスがちょうどそれを接続してあるほど実行しない、AEN1に接続を開始するので

         Listen   <port> = 11

<ポート>=11を聴いてください。

               <AEN 1> = 6

<AEN1>=6

   and when unblocked

そして、いつが「非-妨げ」られましたか?

         Accept   <AEN 2> = 6

<AEN2>=6を受け入れてください。

   When these transactions are complete, the UCLA process is doubly
   connected to the logger at SRI.  The logger will then interrogate the
   UCLA process, and if satisfied, create a new process at SRI.  This
   new process will be tagged with user number X'010005', and both
   connections wil be switched to the new process.  In this case,
   switching the connections to the new process corresponds to "passing
   the console down" in many time-sharing systems.

これらのトランザクションが完全であるときに、UCLAプロセスはSRIのきこりに二倍接続されます。 次に、きこりはUCLAプロセスについて査問するでしょう、そして、満たされているなら、ニュープロセスをSRIに作成してください。 このニュープロセスはユーザ数のX'010005'、および両方の接続wilと共にタグ付けをされるでしょう。ニュープロセスに切り換えられます。 この場合、接続をニュープロセスに切り換えるのは多くの時分割システムによる「コンソールを伝えます」に対応します。

Crocker, et. al.                                               [Page 11]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [11ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

USER LEVEL SOFTWARE

ユーザレベルソフトウェア

   At the user level, subroutines which manage data buffer and format
   input designed for other HOSTs are provided.  It is not mandatory
   that the user use such subroutines, since the user has access to the
   network system calls in his monitor.

ユーザレベルでは、他のHOSTsのために設計されたデータバッファと形式入力を管理するサブルーチンを提供します。 ユーザがそのようなサブルーチンを使用するのは、義務的ではありません、ユーザが彼のモニターでネットワークシステムコールに近づく手段を持っているので。

   In addition to user programming access, it is desirable to have a
   subsystem program at each HOST which makes the network immediately
   accessible from a teletype-like device without special programming.
   Subsystems are commonly used system components such as text editors,
   compilers and interpreters.  An example of a network-related
   subsystem is TELNET, which will allow users at the University of Utah
   to connect to Stanford Research Institute and appear as regular
   terminal users.  It is expected that more sophisticated subsystems
   will be developed in time, but this basic one will render the early
   network immediately useful.

ユーザプログラミングアクセスに加えて、すぐにネットワークを作る各HOSTのサブシステムプログラムをテレタイプのようなデバイスから特別なプログラミングなしでアクセスしやすくするのは望ましいです。 サブシステムはテキストエディタや、コンパイラやインタプリタなどの一般的に使用されたシステムの部品です。 ネットワーク関連のサブシステムに関する例はTELNETです。(そのTELNETはユタ大学のユーザをスタンフォード研究所に接続して、レギュラーの端末ユーザとして現れさせるでしょう)。 より高度なサブシステムが時間内に開発されると予想されますが、基本的なこれは早めのネットワークをすぐに役に立つのに表すでしょう。

   A user at the University of Utah (UTAH) is sitting at a teletype
   dialed into the University's PDP-10/50 time-sharing system.  He
   wishes to operate the Conversational Algebraic Language (CAL)
   subsystem on the XDS-940 at Stanford Research Institute (SRI) in
   Menlo Park, California.  A typical TELNET dialog is illustrated in
   Figure 5.  The meaning of each line of dialogue is discussed here.

ユタ大学(ユタ)のユーザは大学のPDP-10/50時分割システムにダイヤルされたテレタイプに座っています。 彼はメンローパーク(カリフォルニア)でスタンフォード研究所(SRI)でXDS-940でConversational Algebraic Language(CAL)サブシステムを操作したがっています。 典型的なTELNET対話は図5で例証されます。 ここで対話のそれぞれの系列の意味について議論します。

      (i)      The user signs in at UTAH

(i) ユーザはユタでサインインします。

      (ii)     The PDP-10 run command starts up the TELNET subsystem at
               the user's HOST.

(ii) PDP-10実行命令はユーザのHOSTでTELNETサブシステムを立ち上げます。

      (111)    The user identifies a break character which causes any
               message following the break to be interpreted locally
               rather than being sent on the foreign HOST.

(111) ユーザは外国HOSTに送るより局所的にむしろ解釈されるために中断に続いて、どんなメッセージも引き起こす区切り文字を特定します。

      (iv)     The TELNET subsystem will make the appropriate system
               calls to establish a pair of connections to the SRI
               logger.  The connections will be established only if SRI
               accepts another foreign user.

(iv) TELNETサブシステムは、1組の接続をSRIきこりに証明するために適切なシステムコールをするでしょう。 SRIが別の外国人のユーザを受け入れる場合にだけ、接続は確立されるでしょう。

   The UTAH user is now in the pre-logged-in state at SRI.  This is
   analogous to the standard teletype user's state after dialing into a
   computer and making a connection but before typing anything.

ユタユーザはSRIに現在、あらかじめログインされた状態にあります。 コンピュータにダイヤルして、接続を作った後にもかかわらず、何でもタイプする前に、これは標準のテレタイプユーザの状態に類似しています。

      (v)      The user signs in to SRI with a standard login command.
               Characters typed on the user's teletype are transmitted
               unaltered through the PDP-10 (user HOST) and on to the
               940 (serving HOST).  The PDP-10 TELNET will have
               automatically switched to full-duplex, character-by-

(v) ユーザは標準のログインコマンドでSRIにサインインします。 ユーザのテレタイプにタイプされた文字はPDP-10(ユーザHOST)を通して940に非変更されていた状態で伝えられます(HOSTに役立って)。 近くキャラクタ、PDP-10 TELNETが自動的に全二重に切り替わってしまうだろう、-

Crocker, et. al.                                               [Page 12]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [12ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

               character transmission, since this is required by SRI's
               940.  Full duplex operation is allowed for by the PDP-10,
               though not used by most Digital Equipment Corporations
               subsystems.

これがそうである時からキャラクタトランスミッションがSRIの940が必要です。 ほとんどのDECサブシステムで使用されませんが、全二重操作はPDP-10によって考慮されます。

      (vi) and (vii) The 940 subsystem, CAL, is started.

(vi)と(vii)940サブシステム(CAL)は始められます。

   At this point, the user wishes to load a local CAL file into the 940
   CAL subsystem, from the file system on his local PDP-10.

ここに、ユーザは940CALサブシステムにローカルのCALファイルをロードしたがっています、地元のPDP-10の上のファイルシステムから。

      (viii)   CAL is instructed to establish a connection to UTAH in
               order to receive this file.  "NETWRK" is a predefined 940
               name similar in nature to "PAPER TYPE" or "TELETYPE".

(viii)CALがこのファイルを受け取るためにユタに取引関係を築くよう命令されます。 "NETWRK"は「紙のタイプ」か「テレタイプ」と同様の事前に定義された940名です。

      (ix)     Finally, the user types the break character (#) followed
               by a command to his PDP-10 TELNET program, which sends
               the desired file to SRI from Utah on the connection just
               established for this purpose.  The user's next statement
               is in CAL again.

(ix) 最終的に、ユーザは区切り文字(#)をタイプします、続いて、彼のPDP-10 TELNETプログラムにコマンドをタイプします。(それは、ただこのために確立された接続のときに必要なファイルをユタからSRIに送ります)。 CALにはユーザの次の声明が再びあります。

   The TELNET subsystem coding should be minimal for it is essentially a
   shell program built over the network system calls.  It effectively
   established a shunt in the user HOST between the remote user and a
   distant serving HOST.

TELNETサブシステムコード化はそれにおいて最小量であることが、本質的にはネットワークシステムコールの上で組立てられたシェルプログラムであるということであるべきです。 事実上、それはリモート・ユーザーと遠方の給仕HOSTの間のユーザHOSTに転換を設置しました。

   Given the basic system primitives, the TELNET subsystem at the user
   HOST and a manual for the serving HOST, the network can be profitably
   employed by remote users today.

基本体系基関数、ユーザHOSTのTELNETサブシステム、および給仕HOSTのためのマニュアルを考えて、リモート・ユーザーは今日、ネットワークを有益に使うことができます。

HIGHER LEVEL PROTOCOL

より高い平らなプロトコル

   The network poses special problems where a high degree of interaction
   is required between the user and a particular subsystem in a foreign
   HOST.  These problems arise due to heterogeneous consoles, local
   operating systems overhead, and network transmission delays.  Unless
   we use special strategies it may be difficult or even impossible for
   a distant user to make use of the more sophisticated subsystems
   offered.  While these difficulties are especially severe in the area
   of graphics, problems may arise even for teletype interaction.  For
   example, suppose that a foreign subsystem is designed for teletype
   consoles connected by telephone, and then this subsystem becomes
   available to network users.  This subsystem might have the following
   characteristics.

ネットワークは高度合いの相互作用が外国HOSTのユーザと特定のサブシステムの間で必要である特別な問題を引き起こします。これらの問題は異種のコンソール、地方のオペレーティングシステムオーバーヘッド、およびネットワーク送信遅れのため起こります。 私たちが特別な戦略を使用しないなら、冷ややかなユーザが、より高度なサブシステムの使用を提供させるのは、難しいか、または不可能でさえあるかもしれません。 これらの困難がグラフィックスの領域で特に厳しい間、問題はテレタイプ相互作用のためにさえ起こるかもしれません。 例えば、外国サブシステムが電話によって接続されたテレタイプコンソールのために設計されていて、次に、このサブシステムがネットワーク利用者にとって利用可能になると仮定してください。 このサブシステムには、以下の特性があるかもしれません。

      1. Except for echoing and correction of mistyping, no action is
         taken until a carriage return is typed.

1. mistypingの反響と修正以外に、復帰がタイプされるまで、行動を全く取りません。

Crocker, et. al.                                               [Page 13]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [13ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

      2. All characters except "^", and "<-" and carriage returns are
         echoed as the character is typed.

2. すべてのキャラクタが"^"を除きます、そして、文字がタイプされるとき、"<"と復帰はまねられます。

      3. <- causes deletion of the immediately preceding character, and
         is echoed as that character.

3. <。 すぐに前のキャラクタの削除を引き起こして、そのキャラクタとしてまねられます。

      4. ^ causes all previously typed characters to be ignored.  A
         carriage return and line feed are echoed.

4. ^はすべての以前にタイプされたキャラクタを無視させます。 復帰と改行はまねられます。

      5. A carriage return is echoed as a carriage return followed by a
         line feed.

5. 改行で復帰が続いたとき、復帰はまねられます。

   If each character typed is sent in its own message, then the
   characters

それぞれなら、それ自身のメッセージでタイプされた文字を送って、その時はキャラクタです。

      H E L L O <- <- P c.r.

H E L L O<<P c. r。

   cause nine messages in each direction.  Furthermore, each character
   is handled by a user level program in the local HOST before being
   sent to the foreign HOST.

各方向による9つのメッセージを引き起こしてください。 その上、外国HOSTに送る前に地方のHOSTのユーザレベルプログラムで各キャラクタを扱います。

   Now it is clear that if this particular example were important, we
   would quickly implement rules 1 to 5 in a local HOST program and send
   only complete lines to the foreign HOST.  If the foreign HOST program
   could not be modified so as to not generate echoes, then the local
   program could not only echo properly, it could also throw away the
   later echoes from the foreign HOST.  However, the problem is not any
   particular interaction scheme; the problem is that we expect many of
   these kinds of schemes to occur.  We have not found any general
   solutions to these problems, but some observations and conjectures
   may lead the way.

現在、この特定の例が重要であるなら、私たちがローカルのHOSTプログラムで規則が1〜5であるとすぐに実装して、完全な系列だけを外国HOSTに送るのは、明確です。エコーを生成しないように外国HOSTプログラムを変更できないなら、ローカルのプログラムは適切に反映できるだけではなかったでしょうに、また、それが外国HOSTから後のエコーを捨てるかもしれません。しかしながら、問題はあらゆる特定の相互作用体系ではありません。 問題は私たちが起こるようにこれらの種類の体系を多く期待するということです。 私たちはこれらの問題の少しの一般解も見つけていませんが、いくつかの観測と憶説が先頭に立つかもしれません。

   With respect to heterogeneous consoles, we note that although
   consoles are rarely compatible, many are equivalent.  It is probably
   reasonable to treat a model 37 teletype as the equivalent of an IBM
   2741.  Similarly, most storage scopes will form an equivalence class,
   and most refresh display scopes will form another.  Furthermore, a
   hierarchy might emerge with members of one class usable in place of
   those in another, but not vice versa.  We can imagine that any scope
   might be an adequate substitute for a teletype, but hardly the
   reverse.  This observation leads us to wonder if a network-wide
   language for consoles might be possible.  Such a language would
   provide for distinct treatment of different classes of consoles, with
   semantics appropriate to each class.  Each site could then write
   interface programs for its consoles to make them look like network
   standard devices.

異種のコンソールに関して、私たちは、コンソールがめったに互換性がありませんが、多くが同等であることに注意します。 IBM2741の同等物としてモデル37テレタイプを扱うのはたぶん妥当です。 同様に、ほとんどのストレージ範囲が同値類を形成するでしょう、そして、大部分はディスプレイ範囲をリフレッシュします。別のものを形成するでしょう。 その上、階層構造は、別のもののそれらに代わって使用可能な1つのクラスのメンバーと共に現れますが、逆もまた同様に現れないかもしれません。 私たちは、どんな範囲もしかし、テレタイプ、ほとんど逆の適当な代用品であるかもしれないと想像できます。 この観測は、私たちが、コンソールのためのネットワーク全体の言語が可能であるかもしれないかどうかと思うように導きます。 そのような言語は各クラスに適切な意味論がある異なったクラスのコンソールの異なった処理に備えるでしょう。 そして、各サイトは、コンソールでネットワーク標準装置に似るようにインタフェースプログラムを書くかもしれません。

Crocker, et. al.                                               [Page 14]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [14ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

   Another observation is that a user evaluates an interactive system by
   comparing the speed of the system's responses with his own
   expectations.  Sometimes a user feels that he has made only a minor
   request, so the response should be immediate; at other times he feels
   he has made a substantial request, and is therefore willing to wait
   for the response.  Some interactive subsystems are especially
   pleasant to use because a great deal of work has gone into tailoring
   the responses to the user's expectations.  In the network, however, a
   local user level process intervenes between a local console and a
   foreign subsystem, and we may expect the response time for minor
   requests to degrade.  Now it may happen that all of this tailoring of
   the interaction is fairly independent of the portion of the subsystem
   which does the heavy computing or I/O.  In such a case, it may be
   possible to separate a subsystem into two sections.  One section
   would be a "front end" which formats output to the user, accepts his
   input, and controls computationally simple responses such as echoes.
   In the example above, the program to accumulate a line and generate
   echoes would be the front end of some subsystem.  We now take notice
   of the fact that the local HOSTs have substantial computational
   power, but our current designs make use of the local HOST only as a
   data concentrator.  This is somewhat ironic, for the local HOST is
   not only poorly utilized as a data concentrator, it also degrades
   performance because of the delays it introduces.

別の観測はユーザがシステムの応答の速度を彼自身の期待と比べることによって対話的なシステムを評価するということです。 時々、ユーザが、彼が小さい方の要求だけをしたと感じるので、応答は即座であるべきです。 他の時に、彼は、彼がかなりの要求をしたと感じて、したがって、応答を待っても構わないと思います。 大きな仕事にユーザの期待への応答を合わせるために入ったので、いくつかの対話的なサブシステムが使用するために特に快いです。 しかしながら、ネットワークでは、ユーザの地方のレベルプロセスは地方のコンソールと外国サブシステムを仲裁します、そして、私たちは退行するという小さい方の要求のための応答時間を予想するかもしれません。 今、相互作用のこの仕立屋が皆、重いコンピューティングか入出力をするサブシステムの部分からかなり独立しているのは起こるかもしれません。 このような場合には、2つのセクションにサブシステムを切り離すのは可能であるかもしれません。 1つのセクションがユーザに出力をフォーマットして、彼の入力を受け入れて、エコーなどの計算上簡単な応答を制御する「フロントエンド」でしょう。 例では、系列を蓄積して、エコーを生成するプログラムは上では、何らかのサブシステムのフロントエンドでしょう。 私たちは現在、地方のHOSTsにはかなりのコンピュータのパワーがありますが、私たちの現在のデザインが単にデータ集線装置として地方のHOSTを利用するという事実に注意を払います。 これはいくらか皮肉です、地方のHOSTがデータ集線装置として不十分に利用されるだけではないのでそれも導入する遅れのために性能を下げます。

   These arguments have led us to consider the possibility of a Network
   Interface Language (NIL) which would be a network-wide language for
   writing the front end of interactive subsystems.  This language would
   have the feature that subprograms communicate through network-like
   connections.  The strategy is then to transport the source code for
   the front end of a subsystem to the local HOST, where it would be
   compiled and executed.

これらの議論は、私たちが対話的なサブシステムのフロントエンドを書くためにネットワーク全体の言語であるNetwork Interface Language(NIL)の可能性を考えるように導きました。この言語には、副プログラムがネットワークのような接続で伝える特徴があるでしょう。 戦略はそして、サブシステムのフロントエンドのために地方のHOSTにソースコードを輸送することです。そこでは、それは、コンパイルされて、実行されるでしょう。

   During preliminary discussions we have agreed that NIL should have at
   least the following semantic properties not generally found in other
   languages.

予備的な討論の間、私たちは、NILには少なくとも一般に、他の言語で見つけられなかった以下の意味特性があるはずであるのに同意しています。

      1. Concurrency.  Because messages arrive asynchronously on
         different connections, and because user input is not
         synchronized with subsystem output, NIL must include semantics
         to accurately model the possible concurrencies.

1. 並行性。 メッセージが異なった接続のときに非同期に到達して、ユーザ入力がサブシステム出力と同時にしないので、NILは正確に可能な並行性をモデル化するために意味論を含まなければなりません。

      2. Program Concatenation.  It is very useful to be able to insert
         a program in between two other programs.  To achieve this, the
         interconnection of programs would be specified at run time and
         would not be implicit in the source code.

2. 連結をプログラムしてください。 他の2つのプログラムの間でプログラムを差し込むことができるのは非常に役に立ちます。プログラムのインタコネクトは、これを達成するために、ランタイムのときに指定されて、ソースコードで暗黙でないでしょう。

Crocker, et. al.                                               [Page 15]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [15ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

      3. Device substitutability.  It is usual to define languages so
         that one device may be substituted for another.  The
         requirement here is that any device can be modeled by a NIL
         program.  For example, if a network standard display controller
         manipulates tree-structures according to messages sent to it
         then these structures must be easily implementable in NIL.

3. デバイス代替可能性。 言語を定義するのは、別のものに1台のデバイスを代入できるくらい普通です。 NILプログラムでどんなデバイスもモデル化できるという要件がここにあります。 例えば、それに送られたメッセージによると、ネットワーク標準表示コントローラが木構造を操るなら、これらの構造はNILで容易に実装可能でなければなりません。

   NIL has not been fully specified, and reservations have been
   expressed about its usefulness.  These reservations hinge upon our
   conjecture that it is possible to divide an interactive system into a
   transportable front end which satisfies a user's expectations at low
   cost and a more substantial stay-at-home section.  If our conjecture
   is false, then NIL will not be useful; otherwise it seems worth
   pursuing.  Testing of this conjecture and further development of NIL
   will take priority after low level HOST-HOST protocol has stabilized.

NILは完全に指定されるというわけではありませんでした、そして、予約は有用性に関して言い表されました。 これらの予約は対話的なシステムをわずかの費用でユーザの期待を満たす輸送可能なフロントエンドと、より実質的な家にばかりいる人部に分割するのが可能であるという私たちの推測によります。 私たちの推測が誤っているなら、NILは役に立ちません。 さもなければ、それは追求する価値があるように見えます。 HOST-HOSTが議定書の中で述べる低レベルが安定した後にこの推測のテストとNILのさらなる開発は優先するでしょう。

HOST/IMP INTERFACING

ホスト/悪童連結

   The hardware and software interfaces between HOST and IMP is an area
   of particular concern for the HOST organizations.  Considering the
   diversity of HOST computers to which a standard IMP must connect, the
   hardware interface was made bit serial and full-duplex.  Each HOST
   organization implements its half of this very simple interface.

HOSTとIMPとのハードウェアとソフトウェア・インタフェースはHOST組織に関する特別の心配の領域です。 HOSTの多様性を考える場合、IMPが接続しなければならない規格、ハードウェア・インタフェースがどれであったかにされたコンピュータはシリーズと全二重に噛み付きました。 それぞれのHOST組織はこの非常に簡単なインタフェースの半分を実装します。

   The software interface is equally simple and consists of messages
   passed back and forth between the IMP and HOST programs.  Special
   error and signal messages are defined as well as messages containing
   normal data.  Messages waiting in queues in either machine are sent
   at the pleasure of the machine in which they reside with no concern
   for the needs of the other computer.

ソフトウェア・インタフェースは、等しく簡単であり、IMPとHOSTプログラムの間で前後に通過されたメッセージから成ります。特別な誤りと信号メッセージは正常なデータを含むメッセージと同様に定義されます。 それらがもう片方のコンピュータの必要性に関する心配なしで住んでいるマシンの喜びでどちらのマシンでも待ち行列で待つメッセージを送ります。

   The effect of the present software interface is the needless
   rebuffering of all messages in the HOST in addition to the buffering
   in the IMP.  The messages have no particular order other than arrival
   times at the IMP.  The Network Control Program at one HOST (e.g.,
   UTAH) needs waiting RFNM's before all other messages.  At another
   site (e.g., SRI), the NCP could benefit by receiving messages for the
   user who is next to be run.

現在のソフトウェア・インタフェースの効果はIMPでのバッファリングに加えたHOSTでのすべてのメッセージの不必要な再バッファリングです。 メッセージには、IMPへの到着時間以外のどんな特定のオーダーもありません。 1HOST(例えば、ユタ)のNetwork Control Programは他のすべてのメッセージの前に待ちRFNMのものを必要とします。 別のサイト(例えば、SRI)では、NCPは、実行されるために次のユーザのためにメッセージを受け取ることによって、利益を得ることができるでしょう。

   What is needed is coding representing the specific needs of the HOST
   on both sides of the interface to make intelligent decisions about
   what to transmit next over the channel.  With the present software
   interface, the channel in one direction once committed to a
   particular message is then locked up for up to 80 milliseconds!  This
   approaches one teletype character time and needlessly limits full-
   duplex, character by character, interactions over the net.  At the
   very least, the IMP/HOST protocol should be expended to permit each
   side to assist the other in scheduling messages over the channels.

必要であるものはインタフェースの両側のHOSTが次にチャンネルの上に伝えるべきものに関する知的な決定をする特定の必要性を表すコード化です。 そして、現在のソフトウェア・インタフェースで、一度特定のメッセージに心がけた一方向へのチャンネルは80ミリセカンドまで監禁されます! これは、あるテレタイプキャラクタ時間にアプローチして、キャラクタ、ネットの上の相互作用で不必要に完全なデュプレックス、キャラクタを制限します。 少なくとも、IMP/HOSTプロトコルは、それぞれの側がチャンネルの上にスケジューリングメッセージにもう片方を助けることを許可するために費やされるべきです。

Crocker, et. al.                                               [Page 16]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [16ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

CONCLUSIONS

結論

   At this time (February 1970) the initial network of four sites is
   just beginning to be utilized.  The communications system of four
   IMPs and wide band telephone lines have been operational for two
   months.  Programmers at UCLA have signed in as users of the SRI 940.
   More significantly, one of the authors (S. Carr) living in Palo Alto
   uses the Salt Lake PDP-10 on a daily basis by first connecting to
   SRI.  We thus have first hand experience that remote interaction is
   possible and is highly effective.

このとき(1970年2月)、4つのサイトの初期のネットワークによってただ利用され始めています。 4IMPsと広いバンド電話回線のコミュニケーションシステムは2カ月操作上です。 UCLAのプログラマはSRI940のユーザとしてサインインしました。 よりかなり、パロアルトに住んでいる作者(S.カー)のひとりはSRIへの最初に接続するのによる日課でSalt PDP-10湖を使用します。 私たちには、その結果、経験が直接あります。リモート相互作用は、可能であり、高効率です。

   Work on the ARPA network has generated new areas of interest.  NIL is
   one example, and interprocess communication is another.  Interprocess
   communication over the network is a subcase of general interprocess
   communication in a multiprogrammed environment.  The mechanism of
   connections seems to be new, and we wonder whether this mechanism is
   useful even when the processes are within the same computer.

ARPAネットワークに対する仕事は興味がある新しい領域を生成しました。 NILは1つの例です、そして、プロセス間通信は別です。 ネットワークの上のプロセス間通信はマルチプログラムの環境における一般的なプロセス間通信に関する「副-ケース」です。 接続のメカニズムは新しいように思えます、そして、私たちは同じコンピュータの中にプロセスがありさえするときさえ、このメカニズムが役に立つかどうかと思います。

REFERENCES

参照

   1     L. ROBERTS
         "The ARPA network"
         Invitational Workshop on Networks of Computers Proceedings
         National Security Agency 1968 p 115 ff

1 L.ロバーツコンピュータのNetworksの上の「ARPAネットワーク」Invitational Workshop Proceedings国家安全保障局1968p115ff

   2.    R M RUTLEDGE et al
         "An interactive network of time-sharing computers"
         Proceedings of the 24th National Conference
         Association for Computing Machinery 1969 p 431 ff

2. 24番目のNationalコンファレンス計算機学会1969p431ffのR Mラトリッジ他の「時分割コンピュータの対話的なネットワーク」Proceedings

   3.    F E HEART  R E KAHN  S M ORNSTEIN  W R CROWTHER
         D C WALDEN
         "The interface message processors for the ARPA network"
         These Proceedings

3. F E HEART R EカーンS MオーンスティーンW RクラウザーD Cウォルデン「ARPAネットワークのためのインタフェース・メッセージ・プロセッサ」These Proceedings

LIST OF FIGURES

数字のリスト

   Figure 1  Initial network configuration

図1 Initialネットワーク・コンフィギュレーション

   Figure 2  A typical message from a 24-bit machine

図2 24ビットのマシンからのA典型的なメッセージ

   Figure 3  A typical socket

図3 A典型的なソケット

   Figure 4  The relationship between sockets and processes

図4 ソケットとプロセスとの関係

   Figure 5  A typical TELNET dialog.

図5 A典型的なTELNET対話。

             Underlined characters are those types by the user.

アンダーラインを引かれたキャラクタはユーザによるそういったタイプの人です。

Crocker, et. al.                                               [Page 17]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [17ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

                                 SRI
                                _____
                               /     \
                              |  XDS  |
                              |  940  |
                               \_____/
                                  |
                            +----------+
                            |    IMP   |
                            +----------+
                             /   |    \
                            /    |     \
                           /     |      \  +----+    _____
                          /      |       \ | I  |   /     \
       ______     +----+ /       |        \| M  |--|  DEC  |
      /      \    | I  |/        |         | P  |  | PDP-10|
     |   IBM  |---| M  |         |         +----+   \_____/
     | 360/75 |   | P  |\        |
      \______/    +----+ \       |                    UTAH
                          \      |
        UCSB               \     |
                          +----------+
                          |    IMP   |
                          +----------+
                              |
                           ___|___
                          /       \
                         |   XDS   |
                         |(sigma)-7|
                          \_______/

様_____ / \ | XDS| | 940 | \_____/ | +----------+ | 悪童| +----------+ / | \ / | \ / | \ +----+ _____ / | \ | I| / \ ______ +----+ / | \| M|--| 12月| / \ | I|/ | | P| | PDP-10| | IBM|---| M| | +----+ \_____/ | 360/75 | | P|\ | \______/ +----+ \ | ユタ\| UCSB\| +----------+ | 悪童| +----------+ | ___|___ / \ | XDS| |(σ)-7| \_______/

                            UCLA

UCLA

   Figure 1 Initial network configuration

図1 Initialネットワーク・コンフィギュレーション

Crocker, et. al.                                               [Page 18]

RFC 33                   New HOST-HOST Protocol         12 February 1970

etクロッカー、アル。 [18ページ]RFC33の新しいホスト兼ホストプロトコル1970年2月12日

   |<------------ 24bits ----------->|
   |                                 |
   +---------------------------------+
   |                                 |
   |        Leader (32 bits)         |
   |               __________________|
   |              | 100 ---    ----0 |<----16 bits of marking
   +--------------+------------------+
   |                                 |
   |                                 |
   |   Text of messages (96 bits)    |
   |                                 |
   +------------------------+--------+
   | 100-----          ----0|
   +-------^----------------+
           |
           |______16 bits of padding added
                  by the interface

| <。------------ 24ビット----------->|、|、| +---------------------------------+ | | | リーダー(32ビット)| | __________________| | | 100 --- ----0 | <、-、-、--+をマークする16ビット--------------+------------------+ | | | | | メッセージ(96ビット)のテキスト| | | +------------------------+--------+ | 100----- ----0| +-------^----------------+ | |______インタフェースによって加えられた詰め物の16ビット

   Figure 2  A typical message from a 24-bit machine

図2 24ビットのマシンからのA典型的なメッセージ

          24                    8          8
   +----------------------+-----------+----------+
   |  User Number         |           |          |
   +----------------------+-----------+----------+
                                |          |___AEN
                                |
                                |___HOST number
   Figure 3 A typical socket

24 8 8 +----------------------+-----------+----------+ | ユーザ番号| | | +----------------------+-----------+----------+ | |___AEN| |___HOST数の図3 A典型的なソケット

              |<--- connection --->|
   +---------+                      +---------+
   |         |        link          |         |
   | process |--(|--------------|)--| process |
   |         |   ^              ^   |         |
   +---------+   |              |   +---------+
                 |              |
             send socket    receive socket

| <。--- 接続--->| +---------+ +---------+ | | リンク| | | プロセス|--(|--------------|)--| プロセス| | | ^ ^ | | +---------+ | | +---------+ | | 発信、ソケットはソケットを受けます。

   Figure 4 The relationship between sockets and processes

図4 ソケットとプロセスとの関係

         [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Lorrie Shiota 08/00]

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

Crocker, et. al.                                               [Page 19]

etクロッカー、アル。 [19ページ]

一覧

 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 

スポンサーリンク

base64変換の一覧とその詳細サンプルコード

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

上に戻る