RFC672 日本語訳

Network Working Group                               Richard Schantz (BBN-TENEX)
Request for Comments: 672                                              Dec 1974
NIC #31440

ネットワークワーキンググループリチャードSchantz(BBN-TENEX)はコメントのために以下を要求します。 672 1974年12月のNIC#31440

                     A Multi-Site Data Collection Facility

マルチサイトデータ収集施設

        Preface:

以下について前書きしてください。

        This RFC reproduces most of a working document
        prepared during the design and implementation of the
        protocols for the TIP-TENEX integrated system for
        handling TIP accounting. Bernie Cosell (BBN-TIP)
        and Bob Thomas (BBN-TENEX) have contributed to
        various aspects of this work. The system has been
        partially operational for about a month on selected
        hosts. We feel that the techniques described here
        have wide applicability beyond TIP accounting.

このRFCは取り扱いTIP会計のためのTIP-TENEX融合システムのためにプロトコルの設計と実装の間に準備された働くドキュメントの大部分を再生させます。 バーニー・コーセル(BBN-TIP)とボブ・トーマス(BBN-TENEX)はこの仕事の種々相に貢献しました。 システムは選択されたホストの上のおよそ1カ月部分的に操作上です。 私たちは、ここで説明されたテクニックがTIP会計を超えて広い適用性を持っていると感じます。

Section I

セクションI

Protocols for a Multi-site Data Collection Facility

マルチサイトデータ収集施設へのプロトコル

Introduction

序論

     The development of computer networks has provided the
groundwork for distributed computation: one in which a job or task
is comprised of components from various computer systems. In a
single computer system, the unavailability or malfunction of any of
the job components (e.g. program, file, device, etc.) usually
necessitates job termination. With computer networks, it becomes
feasible to duplicate certain job components which previously had no
basis for duplication. (In a single system, it does not matter how
many times a process that performs a certain function is duplicated;
a system crash makes all unavailable). It is such resource
duplication that enables us to utilize the network to achieve high
reliability and load leveling. In order to realize the potential of
resource duplication, it is necessary to have protocols which
provide for the orderly use of these resources. In this document,
we first discuss in general terms a problem of protocol definition
for interacting with a multiply defined resource (server). The
problem deals with providing a highly reliable data collection
facility, by supporting it at many sites throughout the network. In
the second section of this document, we describe in detail a
particular implementation of the protocol which handles the problem
of utilizing multiple data collector processes for collecting
accounting data generated by the network TIPs. This example also
illustrates the specialization of hosts to perform parts of a
computation they are best equipped to handle. The large network
hosts (TENEX systems) perform the accounting function for the small
network access TiPs.

コンピュータネットワークの開発は分散型計算方式のための土台を提供しました: 1つはどのa仕事かタスクで様々なコンピュータ・システムからコンポーネントから成るか。ただ一つのコンピュータ・システムでは、通常、仕事のコンポーネント(例えば、プログラム、ファイル、デバイスなど)のどれかの使用不能か不調が仕事の終了を必要とします。 コンピュータネットワークで、以前に複製の基礎を全く持っていなかったある仕事のコンポーネントをコピーするのは可能になります。 (ただ一つのシステムでは、ある機能を実行するプロセスが何回コピーされるかは重要ではありません; システムクラッシュで、すべてが入手できなくなります。) それは私たちが高信頼性を達成して、平らにすることをロードするのにネットワークを利用するのを可能にするそのようなリソース複製です。 リソース複製の可能性がわかるために、これらのリソースの規則的な使用に備えるプロトコルを持つのが必要です。 本書では、私たちは最初に、aと対話するための定義が定義されたリソース(サーバ)を掛けるというあいまいな言葉でプロトコルの問題について議論します。 多くのサイトでそれをサポートすることによって高信頼性データ収集施設をネットワークに提供するとの問題取引。 このドキュメントの第2セクションで、私たちは詳細にネットワークTIPsによって生成された会計データを集めるのに複数のデータコレクタプロセスを利用するという問題を扱うプロトコルの特定の実装について説明します。 また、この例は、扱うためにそれらを最もよく備えている計算の部品を実行するためにホストの専門化を例証します。 大きいネットワークホスト(TENEXシステム)は小さいネットワークアクセスTiPsのために会計機能を実行します。

     The situation to be discussed is the following: a data
generating process needs to use a data collection service which is
duplicately provided by processes on a number of network machines.
A request to a server involves sending the data to be collected.

議論されるべき状況は以下です: データ生成するプロセスは、多くのネットワークマシンの上でプロセスによってコピーして提供されるデータ取立業務を使用する必要があります。 サーバへの要求は、集められるためにデータを送ることを伴います。

An Initial Approach

初期のアプローチ

     The data generator could proceed by selecting a particular
server and sending its request to that server. It might also take
the attitude that if the message reaches the destination host (the
communication subsystem will indicate this) the message will be
properly processed to completion. Failure of the request Message
would then lead to selecting another server, until the request
succeeds or all servers have been tried.

データゼネレータは、特定のサーバを選択して、そのサーバに要求を送ることによって、続くことができるでしょう。また、それはメッセージがあて先ホストに届くなら(コミュニケーションサブシステムはこれを示すでしょう)メッセージが適切に完成に処理されるという態度を取るかもしれません。 次に、要求Messageの失敗は、別のサーバを選択するのに通じるでしょう、要求が成功するか、またはすべてのサーバが試みられるまで。

                                      -2-

-2-

     Such a simple strategy is a poor one. It makes sense to
require that the servicing process send a positive acknowledgement
to the requesting process. If nothing else, the reply indicates
that the server process itself is still functioning. Waiting for
such a reply also implies that there is a strategy for selecting
another server if the reply is not forthcoming. Herein lies a
problem. If the expected reply is timed out, and then a new request
is sent to another server, we run the risk of receiving the
(delayed) original acknowledgement at a later time. This could
result in having the data entered into the collection system twice
(data duplication). If the request is re-transmitted to the same
server only, we face the possibility of not being able to access a
collector (data loss). In addition, for load leveling purposes, we
may wish to send new requests to some (or all) servers. We can then
use their reply (or lack of reply) as an indicator of load on that
particular instance of the service. Doing this without data
duplication requires more than a simple request and acknowledgement
protocol*.

そのような簡単な戦略は貧しいものです。 それは整備点検プロセスが積極的な承認を要求プロセスに送るのが必要である意味になります。 他に何もであるなら、回答は、サーバプロセス自体がまだ機能しているのを示します。 また、そのような回答を待つのは、回答が用意されていないなら別のサーバを選択するための戦略があるのを含意します。 ここに、偽りのa問題。 外で期待している回答を調節して、次に、新しい要求を別のサーバに送るなら、私たちは後で(延着します)オリジナルの承認を受ける危険を冒します。 これは収集システムにデータを二度(データ複製)入力させるのに結果として生じることができました。 要求が同じサーバだけに再送されるなら、私たちはできないのがコレクタ(データの損失)にアクセスする可能性に直面しています。 さらに、負荷平らにする目的のために、いくつかの(すべて)サーバに新しい要求を送るかもしれなくたいと思います。 そして、私たちは負荷のインディケータとしてその特定のサービスのインスタンスで彼らの回答(または、回答の不足)を使用できます。 データ複製なしでこれをするのは簡単な要求と承認プロトコル*以上を必要とします。

Extension of the Protocol

プロトコルの拡大

     The general protocol developed to handle multiple collection
servers involves having the data generator send the data request to
some (or all) data collectors. Those willing to handle the request
reply with an "I've got it" message. They then await further
notification before finalizing the processing of the data. The data
generator sends a "go ahead" message to one of the replying
collectors, and a "discard" message to all other replying
collectors. The "go ahead" message is the signal to process the
data (i.e. collect permanently), while the "discard" message
indicates that the data is being collected elsewhere and should not
be retained.

複数の収集サーバを扱うために開発された一般的なプロトコルは、データゼネレータに何人かの(すべて)データコレクタにデータ要求を送らせることを伴います。 要求を扱っても構わないと思っているものが「私には、それがある」というメッセージで返答します。 そして、データの処理を成立させる前に、彼らはさらなる通知を待ちます。 データゼネレータは返答しているコレクタのひとりへの「前方に行ってください」メッセージ、および他のすべての返答しているコレクタへの「捨ててください」というメッセージを送ります。 「前方に行ってください」メッセージはデータを処理する信号(すなわち、永久に、集まる)です、「捨ててください」というメッセージは、データがほかの場所に集められていて、保有されるべきでないのを示しますが。

     The question now arises as to whether or not the collector
process should acknowledge receipt of the "go ahead" message with a
reply of its own, and then should the generator process acknowledge
this acknowledgement, etc. We would like to send as few messages as
possible to achieve reliable communication. Therefore, when a state
--------------------

コレクタプロセスがそれ自身の回答がある「前方に行ってください」メッセージについて領収書を受け取ったことを知らせて、ジェネレータが処理されるはずであるならそしてときに受け取ったことを知らせるべきであるかどうかにこの承認などを承認するとき、質問は現在、起こります。 信頼できるコミュニケーションを達成するできるだけわずかなメッセージしか送りたいと思いません。 したがって、時は状態です。--------------------

* If the servers are independent of each other to the extent that if
two or more servers all act on the same request, the end result is
the same as having a single server act on the request, then a simple
request/acknowledgement protocol is adequate. Such may be the case,
for example, if we subject the totality of collected data (i.e. all
data collected by all collectors for a certain period) to a
duplicate detection scan. If we could store enough context in each
entry to be able to determine duplicates, then having two or more
servers act on the data would be functionally equivalent to
processing by a single server.

* サーバが互いから2つ以上のサーバがすべて、同じ要求に影響するなら、結末がただ一つのサーバ条例を要求に持っているのと同じであるという範囲に独立しているなら、簡単な要求/承認プロトコルは適切です。 ケースはそのようなものであるかもしれません、例えば私たちであるなら。写し検出への集まっているデータ(ある期間、すべてのコレクタによって集められたすなわちすべてのデータ)の全体がスキャンする対象。 私たちが写しを決定できるように各エントリーに十分な文脈を保存できるなら、2つ以上のサーバをデータに影響させるのは、ただ一つのサーバで処理に機能上同等でしょうに。

                                      -3-

-3-

is reached for which further acknowledgements lead to a previously
visited state, or when the cost of further acknowledgements outweigh
the increase in reliability they bring, further acknowledgements
become unnecessary.

どのさらなる承認が以前に訪問された状態、またはいつまでそれらがもたらす信頼性の増加を十二分に補ってください、さらなる承認が不要になるというさらなる承認の費用を導くように、達しているか。

     The initial question was should the collector process
acknowledge the "go ahead" message? Assume for the moment that it
should not send such an acknowledgement. The data generator could
verify, through the communication subsystem, the transmission of the
"go ahead" message to the host of the collector. If this message
did not arrive correctly, the generator has the option of
re-transmitting it or sending a "go ahead" to another collector
which has acknowledged receipt of the data. Either strategy
involves no risk of duplication. If the "go ahead" message arrives
correctly, and a collector acknowledgement to the "go ahead" message
is not required, then we incur a vulnerability to (collector host)
system crash from the time the "go ahead" message is accepted by the
host until the time the data is totally processed. Call the data
processing time P. Once the data generator has selected a
particular collector (on the basis of receiving its "I've got it"
message), we also incur a vulnerability to malfunction of this
collector process. The vulnerable period is from the time the
collector sends its "i've got it" message until the time the data is
processed. This amounts to two network transit times (2N) plus IMP
and host overhead for message delivery (0) plus data processing time
(P). [Total time=2N+P+O]. A malfunction (crash) in this period can
cause the loss of data. There is no potential for duplication.

コレクタプロセスが「前方に行ってください」メッセージを承認するなら、初期の質問はそうですか? さしあたり、そのような承認を送るべきでないと仮定してください。 データゼネレータはコミュニケーションサブシステムで「前方に行ってください」メッセージの伝達についてコレクタのホストに確かめるかもしれません。 このメッセージが正しく到着しなかったなら、ジェネレータには、データの領収書を受け取ったことを知らせたそれを再送するか、または別のコレクタへの「前に進んでください」を送るオプションがあります。 戦略は複製の危険を全く伴いません。 「前方に行ってください」メッセージが正しく到着して、「前方に行ってください」メッセージへのコレクタ承認は必要でないなら、私たちが「前方に行ってください」メッセージがホストによって受け入れられる時からデータが完全に処理される時まで(コレクタホスト)システムクラッシュへ脆弱性を被ります。 データゼネレータが特定のコレクタ(「私には、それがある」というメッセージを受け取ることに基づいた)を選んで、また、私たちがこのコレクタプロセスの不調へ脆弱性を被るデータ処理時間P.Onceのときに、電話をしてください。 コレクタが「私には、それがある」というメッセージを送る時からデータが処理される時まで易損期があります。 これはメッセージ配送(0)とデータ処理時間(P)の2つのネットワークトランジット回数(2N)、IMP、およびホストオーバーヘッドに達します。 [合計時は2N+P+Oと等しいです。] この期間の不調(墜落する)はデータの喪失を引き起こす場合があります。 複製の可能性が全くありません。

     Now, assume that the data collector process must acknowledge
the "go ahead" message. The question then arises as to when such an
acknowledgement should be sent. The reasonable choices are either
immediately before final processing of the data (i.c. before the
data is permanently recorded) or immediately after final processing.
It can be argued that unless another acknowledgement is required (by
the generator to the collector) to this acknowledgement BEFORE the
actual data update, then the best time for the collector to
acknowledge the "go ahead" is after final processing. This is so
because receiving the acknowledgement conveys more information if it
is sent after processing, while not receiving it (timeout), in
either case, leaves us in an unknown state with respect to the data
update. Depending on the relative speeds of various network and
system components, the data may or may not be permanently entered.
Therefore if we interpret the timeout as a signal to have the data
processed at another site, we run the risk of duplication of data.
To avoid data duplication, the timeout strategy must only involve
re-sending the "go ahead" message to the same collector. This will
only help if the lack of reply is due to a lost network message.
Our vulnerability intervals to system and process malfunction remain
as before.

今度は、データコレクタプロセスが「前方に行ってください」メッセージを承認しなければならないと仮定してください。 そして、質問はそのような承認が送られるべきである時に関して起こります。 正当な選択がデータ(データの前のi.c.は永久に、記録される)の最終的な処理の直前最終的な処理直後あります。 次に、コレクタが「前方に行ってください」を承認する最も良い時間が別の承認がデータがアップデートする実際のこの承認に必要な(コレクタへのジェネレータによる)BEFOREでないなら、最終的な処理の後にあると主張できます。 したがってこれは承認を受けると処理がどちらの場合でもそれ(タイムアウト)を受けていない間、未知の状態にデータ最新版に関して私たちを置き去りにした後にそれを送るなら詳しい情報が伝えられるからです。 様々なネットワークとシステムの部品の相対速度によって、データは永久に、入力されるかもしれません。 したがって、別のサイトでデータを処理させるために信号としてタイムアウトを解釈するなら、私たちはデータの重複の危険を冒します。 データ重複を避けるために、タイムアウト戦略は、「前方に行ってください」メッセージを同じコレクタに再送することを伴うだけでよいです。 これは回答の不足が無くなっているネットワークメッセージのためである場合にだけ助けるでしょう。 システムとプロセス不調への私たちの脆弱性間隔は従来と同様残っています。

     It is our conjecture (to be analyzed further) that any further
acknowledgements to these acknowledgements will have virtually no
effect on reducing the period of vulnerability outlined above. As
such, the protocol with the fewest messages required is superior.

それは上に概説された脆弱性の期間を短縮するときもうこれらの承認への何も承認が実際には効き目がないという私たちの推測(さらに分析される)です。 そういうものとして、最もわずかなメッセージしか必要でないことのプロトコルは優れています。

                                      -4-

-4-

Data Dependent Aspects of the Protocol

プロトコルのデータに依存する局面

     As discussed above, a main issue is which process should be the
last to respond (send an acknowledgement). If the data generator
sends the last message (i.e. "go ahead"), we can only check on its
correct arrival at the destination host. We must "take on faith"
the ability of the collector to correctly complete the transaction.
This strategy is geared toward avoiding data duplication. If on the
other hand, the protocol specifies that the collector is to send the
last message, with the timeout of such a message causing the data
generator to use another collector, then the protocol is geared
toward the best efforts of recording the data somewhere, at the
expense of possible duplication.

上で議論するように、本題はどのプロセスが反応させる最終であるべきであるかということ(承認を送る)です。 データゼネレータが最後のメッセージを送るなら(すなわち、「前に進んでください」)、私たちはあて先ホストへの正しい到着について検査できるだけです。 私たちはコレクタが正しく取引を完了する能力を「信頼では、取らなければなりません」。 データ重複を避けることに向かってこの戦略は連動します。 他方では、プロトコルが、コレクタが最後のメッセージを送ることになっていると指定するなら、データゼネレータが別のコレクタを使用するそのようなメッセージのタイムアウトでプロトコルはどこかにデータを記録する最善の努力に向かって連動します、可能な複製を犠牲にして。

     Thus, the nature of the problem will dictate which of the
protocols is appropriate for a given situation. The next section
deals in the specifics of an implement;tion of a data collection
protocol to handle the problem of collecting TIP accounting data by
using the TENEX systems for running the collection server processes.
It is shown how the general protocol is optimized for the accounting
data collection.

したがって、問題の性格は、与えられた状況に、プロトコルのどれが適切であるかを決めるでしょう。 次のセクションは道具の詳細を扱います; 収集サーバプロセスを実行するTENEXシステムを使用することによってTIP会計データを集めるという問題を扱うデータ収集プロトコルのtion。 それは一般的なプロトコルが会計データ収集のためにどのように最適化されるかが示されます。

Section II

セクションII

Protocol for TIP-TENEX Accounting Server Information Exchange

チップ-TENEX会計サーバ情報交換のためのプロトコル

Overview of the Facility

施設の概要

     When a user initially requests service from a TIP, the TIP will
perform a broadcast ICP to find an available RSEXEC which maintains
an authentication data base. The user must then complete s login
sequence in order to authenticate himself. If he is successful the
RSEXEC will transmit his unique ID code to the TIP. Failure will
cause the RSEXEC to close the connection and the TIP to hang up on
the user. After the user is authenticated, the TIP will accumulate
accounting data for the user session. The data includes a count of
messages sent on behalf of the user, and the connect time for the
user. From time to time the TIP will transmit intermediate
accounting data to Accounting Server (ACTSER) processes scattered
throughout the network. These accounting servers will maintain
files containing intermediate raw accounting data. The raw
accounting data will periodically be collected and sorted to produce
an accounting data base. Providing a number of accounting servers
reduces the possibility of being unable to find a repository for the
intermediate data, which otherwise would be lost due to buffering
limitations in the TiPs. The multitude of accounting servers can
also serve to reduce the load on the individual hosts providing this
facility.

ユーザが初めはTIPからサービスを要求するとき、TIPは、認証データベースを維持する利用可能なRSEXECを見つけるために放送ICPを実行するでしょう。 そして、ユーザは、自分を認証するためにsログイン系列を完了しなければなりません。 彼がうまくいくと、RSEXECは彼の固有のIDコードをTIPに伝えるでしょう。 失敗で、RSEXECは、ユーザにハングアップするように接続とTIPを終えるでしょう。 ユーザが認証された後に、TIPはユーザセッションのための会計データを蓄積するでしょう。 データはユーザのためにユーザ、および接続時間を代表して送られたメッセージのカウントを含んでいます。 時々、TIPはネットワーク中に点在するAccounting Server(ACTSER)プロセスに中間的会計データを送るでしょう。 これらの会計サーバは中間的生の会計データを含むファイルを保守するでしょう。 生の会計データは、会計データベースを作り出すために定期的に集められて、分類されるでしょう。 多くの会計サーバを提供すると、TiPsで制限をバッファリングするためそうでなければ失われるだろう中間的データに関して倉庫を見つけることができない可能性は減少します。 また、会計サーバの多数が、この施設を提供しながら個々のホストで負荷を減少させるのに勤めることができます。

                                      -5-

-5-

The rest of this document details the protocol that has been
developed to ensure delivery of TIP accounting data to one of the
available accounting servers for storage in the intermediate
accounting files.

このドキュメントの残りは中間的課金ファイルにおけるストレージのための利用可能な会計サーバの1つにTIP会計データの配送を確実にするために開発されたプロトコルを詳しく述べます。

Adapting the Protocol

プロトコルを適合させます。

The TIP to Accounting Server data exchange uses a protocol that
allows the TIP to select for data transmission one, some, or all
server hosts either sequentially or in parallel, yet insures that
the data that becomes part of the accounting file does not contain
duplicate information. The protocol also minimizes the amount of
data buffering that must be done by the limited capacity TiPs. The
protocol is applicable to a wide class of data collection problems
which use a number of data generators and collectors. The following
describes how the protocol works for TIP accounting.

Accounting Serverデータ交換へのTIPは、TIPがデータ伝送1、いくつか、またはすべてのサーバのために連続するか平行でホストを選ぶことができるプロトコルを使用しますが、課金ファイルの一部になるデータが写し情報を含まないのを保障します。 また、プロトコルは収容数の限界TiPsがしなければならないデータ量バッファリングを最小にします。 プロトコルは多くのデータゼネレータとコレクタを使用する広いクラスのデータ収集問題に適用可能です。 以下はプロトコルがTIP会計でどう働いているかを説明します。

Each TIP is responsible for maintaining in its memory the cells
indicating the connect time and the number of messages sent for each
of its current users. These cells are incremented by the TIP for
every quantum of connect time and message sent, as the case may be.
This is the data generation phase. Periodically, the TIP will scan
all its active counters, and along with each user ID code, pack the
accumulated data into one network message (i.e. less than 8K bits).
The TIP then transmits this data to a set of Accounting Server
processes residing throughout the network. The data transfer is
over a specially designated host-host link. The accounting servers
utilize the raw network message facility of TENEX 1.32 in order to
directly access that link. When an ACTSER receives a data message
from a TIP, it buffers the data and replies by returning the entire
message to the originating TIP. The TIP responds with a positive
acknowledgement ("go ahead") to the first ACTSER which returns the
data, and responds with a negative acknowledgement ("discard") to
all subsequent ACTSER data return messages for this series of
transfers. If the TIP does not receive a reply from any ACTSER, it
accumulates new data (i.e. the TIP has all the while been
incrementing its local counters to reflect the increased connect
time and message count; the current values will comprise new data
transfers) and sends the new data to the Accounting Server
processes. When an ACTSER receives a positive acknowledgement from
a TIP (i.e. "go ahead"), it appends the appropriate parts of the
buffered data to the locally maintained accounting information file.
On receiving a negative acknowledgement from the TIP (i.e.
"discard"), the ACTSER discards the data buffered for this TIP. In
-addition, when the TIP responds with a "go ahead" to the first
ACTSER which has accepted the data (acknowledged by returning the
data along with the "I've got it"), the TIP decrements the connect
time and message counters for each user by the amount indicated in
the data returned by the ACTSER. This data will already be
accounted for in the intermediate accounting files.

メモリでセルがそれぞれ注文された現在のユーザのメッセージの接続時間を示して、数であることを支持するのにそれぞれのTIPは責任があります。 これらのセルは接続時間のあらゆる量子と場合によって送られたメッセージのためにTIPによって増加されます。 これはデータ生成フェーズです。 定期的に、TIPは1つのネットワークメッセージ(すなわち、8Kのビット)にすべてのアクティブなカウンタ、およびそれぞれのユーザIDコード、パックに伴う累積データをスキャンするでしょう。 そして、TIPはネットワーク中に住んでいる1セットのAccounting Serverプロセスにこのデータを送ります。 特に、指定されたホスト兼ホストリンクの上にデータ転送があります。 会計サーバは、直接そのリンクにアクセスするのにTENEX1.32の生のネットワークメッセージ施設を利用します。 ACTSERがTIPからデータメッセージを受け取るとき、それは、全体のメッセージを起因しているTIPに返すことによって、データと回答をバッファリングします。 TIPは積極的な承認(「前に進む」)でデータを返す最初のACTSERに応じて、否定的承認(「破棄」)でこのシリーズの転送へのすべてのその後のACTSERデータリターンメッセージに応じます。 TIPがどんなACTSERからも回答を受け取らないなら、それは、新しいデータ(すなわち、TIPは増強された接続時間とメッセージカウントを反映するためにずっと地方のカウンタを増加しています; 現行価値は新しいデータ転送を包括する)を蓄積して、新しいデータをAccounting Serverプロセスに送ります。 ACTSERがTIPから積極的な承認を受けるとき(すなわち、「前に進んでください」)、それはバッファリングされたデータの適切な部分を局所的に維持された課金情報ファイルに追加します。 TIP(すなわち、「捨てる」)から否定的承認を受けると、ACTSERはこのTIPのためにバッファリングされたデータを捨てます。 TIPが最初のACTSERへの「前に進んでください」で応じるとき、追加では、どれがデータを受け入れたか、(データを返すと認める、「私には、それがある」)、ACTSERによって返されたデータで示された量に従って、TIPは各ユーザのために接続時間とメッセージカウンタを減少させます。 このデータは中間的課金ファイルで既に説明されるでしょう。

As an aid in determining which ACTSER replies are to current
requests, and which are tardy replies to old requests, the TIP

現在の要求にはどのACTSER回答があるか、そして、どれが古い要求、TIPへの遅い回答であるかを決定することにおける援助として

                                      -6-
maintains a sequence number indicator, and appends this number to
each data message sent to an ACTSER. On receiving a reply from an
ACTSER, the TIP merely checks the returned sequence number to see if
this is the first reply to the current set of TIP requests. If the
returned sequence number is the same as the current sequence number,
then this is the first reply; a positive acknowledgement is sent
off, the counters are decremented by the returned data, and the
sequence number is incremented. If the returned sequence number is
not the same as the current one (i.e. not the one we are now
seeking a reply for) then a negative acknowledgement is sent to the
replying ACTSER. After a positive acknowledgement to an ACTSER (and
the implied incrementing of the sequence number), the TIP can wait
for more information to accumulate, and then start transmitting
again using the new sequence number.

-6、-、ACTSERに送られたそれぞれのデータメッセージに、一連番号インディケータを維持して、この数を追加します。 ACTSERから回答を受け取ると、TIPは、これが現在のセットのTIP要求に関する最初の回答であるかどうか確認するために単に返された一連番号をチェックします。 返された一連番号が現在の一連番号と同じであるなら、これは最初の回答です。 積極的な承認を送ります、そして、返されたデータでカウンタを減少させます、そして、一連番号は増加しています。 返された一連番号が現在のものと同じでないなら(すなわち、私たちが現在回答を求めているものでない)、否定的承認を返答しているACTSERに送ります。 ACTSER(そして、一連番号の暗示している増加)への積極的な承認の後に、TIPは蓄積する詳しい情報、および次に再び新しい一連番号を使用することで伝わる始めを待つことができます。

Further Clarification of the Protocol

プロトコルのさらなる明確化

There are a number of points concerning the protocol that
should be noted.

注意されるべきであるプロトコルに関して多くのポイントがあります。

1. The data generator (TIP) can send different (i.e. updated
versions) data to different data collectors (accounting servers) as
part of the same logical transmission sequence. This is possible
because the TIP does not account for the data sent until it receives
the acknowledgement of the data echo. This strategy relieves the
TIP of any buffering in conjunction with re-transmission of data
which hasn't been acknowledged.

1. データゼネレータ(TIP)は同じ論理的なトランスミッション系列の一部として異なった(すなわち、バージョンをアップデートする)データを異なったデータコレクタ(会計サーバ)に送ることができます。 TIPがそれがデータエコーの承認を受けるまで送られたデータを説明しないので、これは可能です。 この戦略は承認されていないデータの再伝達に関連してどんなバッファリングもTIPに取り除きます。

2. A new data request to an accounting server from a TIP will
also serve as a negative acknowledgement concerning any data already
buffered by the ACTSER for that TIP, but not yet acknowledged. The
old data will be discarded, and the new data will be buffered and
echoed as an acknowledgement. This allows the TIP the option of not
sending a negative acknowledgement when it is not convenient to do
so, without having to remember that it must be sent at a later time.
There is one exception to this convention. If the new data message
has the same sequence number as the old buffered message, then the
new data must be discarded, and the old data kept and re-echoed.
This is to prevent a slow acknowledgement to the old data from being
accepted by the TIP, after the TIP has already sent the new data to
the slow host. This caveat can be avoided if the TIP does not
resend to a non-responding server within the time period that a
message could possibly be stuck in the network, but could still be
delivered. Ignoring this situation may result in some accounting
data being counted twice. Because of the rule to keep old data when
confronted with matching sequence numbers, on restarting after a
crash, the TIP should send a "discard" message to all servers in
order to clear any data which has been buffered for it prior to the
crash. An alternative to this would be for the TIP to initialize
its sequence number from a varying source such as time of day.

2. また、TIPからの会計サーバへの新しいデータ要求は否定的承認としてそのTIPのためにACTSERによって既にバッファリングされますが、まだ承認されていなかった少しのデータに関しても機能するでしょう。 古いデータが捨てられて、新しいデータは、承認としてバッファリングされて、反映されるでしょう。 これはそうするのが便利でないときに否定的承認を送らないオプションをTIPに許容します、後でそれを送らなければならなかったのを覚えている必要はなくて。 このコンベンションへの1つの例外があります。 新しいデータメッセージに古いバッファリングされたメッセージと同じ一連番号があるなら新しいデータが捨てなければならなくて、古いデータは、保って、再反映しました。 これは古いデータへの遅い承認がTIPによって受け入れられるのを防ぐためのものです、TIPが既に新しいデータを遅いホストに送った後に。 この警告はTIPが期間中に無回答のサーバにそれを再送しないなら避けられて、メッセージをネットワークで張り付けることができましたが、まだ提供できたということであるかもしれません。 この状況を無視すると、二度数えられるいくつかの会計データがもたらされるかもしれません。 守る規則のために、TIPがクラッシュの後に再開するときそうするべきである合っている一連番号に立ち向かわれていると、古いデータは、クラッシュの前にそれのためにバッファリングされたどんなデータもクリアするために「捨ててください」というメッセージをすべてのサーバに送ります。 これへの代替手段はTIPが時刻などの異なった源から一連番号を初期化するだろうことです。

3. The accounting server similarly need not acknowledge receipt
of data (by echoing) if it finds itself otherwise occupied. This
will mean that the ACTSER is not buffering the data, and hence is
not a candidate for entering the data into the file. However, the

3. それが別の方法で気付くと占領されているなら、会計サーバは同様にデータ(反響するのによる)の領収書を受け取ったことを知らせる必要はありません。 これはACTSERがデータをバッファリングしていなくて、またしたがって、ファイルの中にデータを入力する候補でないことを意味するでしょう。 しかしながら

                                      -7-
TIP may try this ACTSER at a later time (even with the same data),
with no ill effects.

-7 -TIPは後で(同じデータがあっても)害なしでこのACTSERを試みるかもしれません。

4. Because of 2 and 3 above, the protocol is robust with respect
to lost or garbled transmissions of TIP data requests and accounting
server echo replies. That is, in the event of loss of such a
message, a re-transmission will occur as the normal procedure.

4. 2と3のために、上では、プロトコルがTIPデータ要求と会計サーバエコー・リプライの無くなっているか誤り伝えられた送信に関して強健です。 すなわち、そのようなメッセージの損失の場合、再トランスミッションは正常な手順として起こるでしょう。

5. There is no synchronization problem with respect to the
sequence number used for duplicate detection, since this number is
maintained only at the TIP site. The accounting server merely
echoes the sequence number it has received as part of the data.

5. 写し検出に使用される一連番号に関して同期問題が全くありません、この数がTIPサイトだけで維持されるので。 会計サーバは単にそれがデータの一部として受けた一連番号を反響します。

6. There are, however, some constraints on the size of the
sequence number field. It must be large enough so that ALL traces
of the previous use of a given sequence number are totally reMoved
from the network before the number is re-used by the TIP. The
sequence number is modulo the size of the largest number represented
by the number of bits allocated, and is cyclic. Problems generally
arise when a host proceeds from a service interruption while it was
holding on to a reply. If during the service interruption, we have
cycled through our sequence numbers exactly N times (where N is any
integer), this VERY tardy reply could be mistaken for a reply to the
new data, which has the same sequence number (i.e. N revolutions of
sequence numbers later). By utilizing a sufficiently large sequence
number field (16 bits), and by allowing sufficient time between
instances of sending new data, we can effectively reduce the
probability of such an error to zero.

6. しかしながら、いくつかの規制が一連番号分野のサイズにあります。 それが十分大きくなければならないので、数がTIPによって再使用される前に、与えられた一連番号の以前の使用のすべての跡が完全にネットワークからのreMovedです。 一連番号は、割り当てられたビットの数に従って最多数のサイズが表した法であり、周期的です。 回答にしっかりつかまっていた間、ホストが停電から進んでいると、一般に、問題は起こります。 私たちが停電の間、私たちの一連番号を通してちょうどN回自転車で行っているなら(Nがあらゆる整数であるところ)、この非常に遅い回答は新しいデータに関する回答に間違えられるかもしれません。(データには、同じ一連番号(すなわち、一連番号のN革命のちほど)があります)。 十分大きい一連番号分野(16ビット)を利用して、十分な時間発信のインスタンスの間に新しいデータを許容することによって、事実上、私たちはそのような誤りの確率をゼロまで減少させることができます。

7. Since the data involved in this problem is the source of
accounting information, care must be taken to avoid duplicate
entries. This must be done at the expense of potentially losing
data in certain instances. Other than the obvious TIP malfunction,
there are two known ways of losing data. One is the situation where
no accounting server responds to a TIP for an extended period of
time causing the TIP counters to overflow (highly unlikely if there
are sufficient Accounting Servers). In this case, the TIP can hold
the counters at their maximum value until a server comes up, thereby
keeping the lost accounting data at its minimum. The other
situation results from adapting the protocol to our insistence on no
duplicate data in the incremental files. We are vulnerable to data
loss with no recourse from the time the server receives the "go
ahead" to update the file with the buffered data (i.e. positive
acknowledgement) until the time the update is completed and the file
is closed. An accounting server crash during this period will cause
that accounting data to be lost. In our initial implementation, we
have slightly extended this period of vulnerability in order to save
the TIP from having to buffer the acknowledged data for a short
period of time. By updating TIP counters from the returned data in
parallel with sending the "go ahead" acknowledgement, we relieve the
TIP of the burden of buffering this data until the Request for Next
Message (RFNM) from the accounting server IMP is received. This
adds slightly to our period of vulnerability to malfunction, moving
the beginning of the period from the point when the ACTSER host
receives the "go ahead", back to the point when the TIP sends off

7. この問題にかかわるデータが課金情報の源であるので、写しエントリーを避けるために注意しなければなりません。 潜在的にあるインスタンスにおけるデータを失うことを犠牲にしてこれをしなければなりません。 明白なTIP不調を除いて、データを失う2つの知られている方法があります。 1つがTIPカウンタがあふれることを引き起こしながら会計サーバが全く時間の長期間の間にTIPに反応しない状況である、(非常にありそうもない、十分なAccounting Serversがある、) この場合、サーバが来るまで、TIPはそれらの最大値でカウンタを開催できます、その結果、最小限で無くなっている会計データを保ちます。 増加のファイルで重複データでないところの他のプロトコルを適合させるのから私たちの主張までの状況結果。 私たちは償還請求なしでデータの損失にサーバがバッファリングされたデータ(すなわち、積極的な承認)でファイルをアップデートするために「前方に行ってください」を受ける時からアップデートが完成して、ファイルが終えられる時まで被害を受け易いです。 この期間の会計サーバクラッシュで、その会計データを失うでしょう。 初期の実装では、私たちは、短期間の間、認知データをバッファリングしなければならないのでTIPを取っておくためにこの期間の脆弱性をわずかに広げました。 「前方に行ってください」に承認を送ることと平行して返されたデータからTIPカウンタをアップデートすることによって、私たちは会計サーバIMPからのNext Message(RFNM)のためのRequestが受け取られているまでこのデータをバッファリングする負担をTIPに取り除きます。 これは誤動作するようにわずかに私たちの脆弱性の期間に加えます、TIPが離れて発信するACTSERホストが「前方に行ってください」を受けるときのポイントからポイントまでの期初を動かして

                                      -8-

-8-

the "go ahead" (i.e. a period of one network transit time plus some
IMP processing time). However, loss of data in this period is
detectable through the Host Dead or Incomplete Transmission return
in place of the RFNM. We intend to record such occurrences with the

「前方に行ってください。」(すなわち、あるネットワークトランジット時間といくらかのIMP処理時間の期間) しかしながら、この期間のデータの喪失はHost DeadかIncomplete TransmissionリターンでRFNMに代わって検出可能です。 私たちはそのような発生を記録するつもりです。

Network Control Center. If this data loss becomes intolerable, the
TIP program will be modified to await the RFNM for the positive
acknowledgement before updating its counters. In such a case, if
the RFNM does not come, the TIP can discard the buffered data and
re-transmit new data to other servers.

コントロールセンターをネットワークでつないでください。 このデータの損失が堪え難くなると、TIPプログラムは、カウンタをアップデートする前に積極的な承認のためにRFNMを待つように変更されるでしょう。 このような場合には、RFNMが来ないなら、TIPはバッファリングされたデータを捨てて、他のサーバに新しいデータを再送できます。

8. There is adequate protection against the entry of forged data
into the intermediate accounting files. This is primarily due to
the system enforced limited access to Host-Imp messages and
Host-Host links. In addition, messages received on such designated
limited access links can be easily verified as coming from a TIP.
The IMP subnet appends the signature (address) of the sending host
to all of its messages, so there can be no forging. The Accounting
Server is in a position to check if the source of the message is in
fact a TIP data generator.

8. 中間的課金ファイルの中に偽造データのエントリーに対する適切な保護があります。 これは主としてHost-悪童メッセージとHost-ホストリンクへのシステムの実施された限られたアクセスのためです。 さらに、TIPから来ることを容易に限られたアクセスリンクに指定されたそのようなものに受け取られたメッセージについて確かめることができます。 IMPサブネットが送付ホストの署名(アドレス)をメッセージのすべてに追加するので、鍛造できてはいけません。 Accounting Serverが事実上、メッセージの源がTIPデータゼネレータであるかどうかチェックする立場にあります。

Current Parameters of the Protocol

プロトコルの現在のパラメタ

In the initial implementation, the TIP sends its accumulated
accounting data about once every half hour. If it gets no positive
acknowledgement, it tries to send with greater frequency (about
every 5 minutes) until it finally succeeds. It can then return to
the normal waiting period. (A TIP user logout introduces an
exception to this behavior. In order to re-use the TIP port and its
associated counters as soon as possible, a user terminating his TIP
session causes the accounting data to be sent immediately).
initially, our implementation calls for each TIP to remember a
"favored" accounting server. At the wait period expiration, the TIP
will try to deposit the data at its "favored" site. If successful
within a short timeout period, this site remains the favored site,
and the wait interval is reset. If unsuccessful within the short
timeout, the data can be sent to all servers*. The one replying
first will update its file with the data and also become the
"favored" server for this TIP. With these parameters, a host would
have to undergo a proceedable service interruption of more than a
year in order for the potential sequence number problem outlined in
(6) above to occur.

初期の実装では、TIPは蓄積された会計データをあらゆる半毎時のおよそ一度送ります。 どんな積極的な承認も得ないなら、それは、より大きい頻度(5分毎に関する)と共に最終的に成功するまで発信しようとします。 そして、それは正常な待ちの期間まで戻ることができます。 (TIPユーザはログアウトします。この振舞いに例外を紹介します。 できるだけ早くTIPポートとその関連カウンタを再使用するために、彼のTIPセッションを終えるユーザはすぐに、会計データを送らせます。). 初めは、私たちの実装は、各TIPが「好評な」会計サーバを覚えているように求めます。待ち期間の満了のときに、TIPは「好評な」サイトにデータを預けようとするでしょう。 短いタイムアウト時間以内にうまくいくなら、このサイトは好評なサイトのままで残っています、そして、待ち間隔はリセットされます。 短いタイムアウトの中で失敗しているなら、すべてのサーバ*にデータを送ることができます。最初に返答するのは、データでファイルをアップデートして、また、このTIPのために「好評な」サーバになるでしょう。 これらのパラメタで、ホストは起こるように上に(6)に概説された潜在的一連番号問題において、整然としている1年以上の「続-可能」停電を受けなければならないでしょう。

Concluding Remarks

結びの言葉

When the implementation is complete, we will have a general
data accumulation and collection system which can be used to gather
a wide variety of information. The protocol as outlined is geared
to gathering data which is either independent of the previously
accumulated data items (e.g. recording names), or data which
adheres to a commutative relationship (e.g. counting). This is a

実装が完全であるときに、私たちには、さまざまな情報を集めるのに使用できる一般データ蓄積と収集システムがあるつもりです。 概説されるとしてのプロトコルは資料を取り集めるのに以前に蓄積されたデータ項目(例えば、名前を記録する)、または交換可能な関係を固く守るデータ(例えば、数える)から独立している適合しています。 これはaです。

                                      -9-

-9-

consequence of the policy of retransmission of different versions of
the data to different potential collectors (to relieve TIP buffering
problems).

異なった潜在的コレクタ(問題をバッファリングするTIPを救う)へのデータの異なった見解の「再-トランスミッション」の方針の結果。

In the specified version of the protocol, care was taken to
avoid duplicate data entries, at the cost of possibly losing some
data through collector malfunction. Data collection problems which
require avoiding such loss (at the cost of possible duplication of
some data items) can easily be accommodated with a slight adjustment
to the protocol. Collected data which does not adhere to the
commutative relationship indicated above, can also be handled by
utilizing more buffer space at the data generator sites.

プロトコルの指定されたバージョンでは、重複データエントリーを避けるために注意しました、ことによるとコレクタ不調を通していくつかのデータを失う費用で。 わずかな調整で容易にそのような損失(いくつかのデータ項目の可能な複製の費用における)を避けるのを必要とするデータ収集問題にプロトコルに対応できます。 交換可能な関係を固く守らない集まっているデータは、上で示して、また、データゼネレータサイトで、より多くのバッファ領域を利用することによって、扱うことができます。

The sequence number can be incremented for this new set of data
messages, and the new data can also be sent to the slow host. In
this way we won't be giving the tardy response from the old favored
host unfair advantage in determining which server can respond most
quickly. If there is no reply to this series of messages, the TIP
can continue to resend the new data. However, the sequence number
should not be incremented, since no reply was received, and since
indiscriminate incrementing of the sequence number increases the
chance of recycling during the lifetime of a message.

この新しいセットのデータメッセージのために一連番号を増加できます、そして、また、新しいデータを遅いホストに送ることができます。 私たちが年取った好評なホストからしぶしぶの返答を与えないこのように、どのサーバを決定するかにおける不正な利益は最もすばやく応じることができます。 このシリーズのメッセージに関する回答が全くなければ、TIPは、新しいデータを再送し続けることができます。 しかしながら、回答を全く受け取らなかったので増加しているべきでなくて一連番号の無差別の増加以来の一連番号はメッセージの生涯再生するという可能性を増強します。

                                     -10-

-10-