RFC816 日本語訳

RFC:  816

RFC: 816

                      FAULT ISOLATION AND RECOVERY

欠点孤立と回復

                             David D. Clark
                  MIT Laboratory for Computer Science
               Computer Systems and Communications Group
                               July, 1982

デヴィッドD.クラークMITコンピュータサイエンス研究所コンピュータシステムズとコミュニケーションは1982年7月に分類されます。

     1.  Introduction

1. 序論

     Occasionally, a network or a gateway will go down, and the sequence

時折、ネットワークかゲートウェイが下に碁、および系列を望んでいます。

of  hops  which the packet takes from source to destination must change.

パケットがソースから取るホップでは、目的地は変化しなければなりません。

Fault isolation is that action which  hosts  and  gateways  collectively

欠点孤立、その動作がどのホストとゲートウェイであるか、まとめ

take  to  determine  that  something  is  wrong;  fault  recovery is the

取って、何か問題があることを決定してください。 欠点回復はそうです。

identification and selection of an alternative route which will serve to

意志が役立つ代替のルートの識別と選択

reconnect the source to the destination.  In fact, the gateways  perform

ソースを目的地に再接続してください。 事実上、ゲートウェイは働きます。

most  of  the  functions  of  fault  isolation and recovery.  There are,

欠点孤立と回復の機能の大部分。 あります。

however, a few actions which hosts must take if they wish to  provide  a

しかしながら、ホストが彼らであるなら取らなければならないいくつかの行動がaを提供したがっています。

reasonable  level  of  service.   This document describes the portion of

妥当な水準のサービス。 このドキュメントは部分について説明します。

fault isolation and recovery which is the responsibility of the host.

ホストの責任である欠点孤立と回復。

     2.  What Gateways Do

2. ゲートウェイがすること

     Gateways collectively implement an algorithm which  identifies  the

ゲートウェイがアルゴリズムをまとめて実行する、どれ、特定

best  route  between  all pairs of networks.  They do this by exchanging

すべての組のネットワークの間で最もよく発送します。 彼らは、交換することによって、これをします。

packets  which  contain  each  gateway's  latest   opinion   about   the

各ゲートウェイの最新の意見を含むおよそパケット

operational status of its neighbor networks and gateways.  Assuming that

その隣人ネットワークとゲートウェイの操作上の状態。 それを仮定します。

this  algorithm is operating properly, one can expect the gateways to go

このアルゴリズムが適切に作動することである、人はゲートウェイが行くと予想できます。

through a period of confusion immediately after some network or  gateway

                                   2

何らかのネットワークかゲートウェイ2直後混乱の1回の時代を通して

has  failed,  but  one  can assume that once a period of negotiation has

失敗されるのにもかかわらずの、1缶にかつての交渉の一区切りがそうしたと仮定させます。

passed, the gateways are equipped with a consistent and correct model of

通って、ゲートウェイは一貫して正しいモデルに持たせます。

the connectivity of the internet.  At present this period of negotiation

インターネットの接続性。 現在のところこの期間の交渉

may actually take several minutes, and many TCP implementations time out

実際に、数分、および多くのTCP実現タイムアウトがかかるかもしれません。

within that period, but it is a design goal of  the  eventual  algorithm

その期間中に、唯一のそれは最後のアルゴリズムのデザイン目標です。

that  the  gateway  should  be  able to reconstruct the topology quickly

ゲートウェイはすぐにトポロジーを再建するはずであることができます。

enough that a TCP connection should be able to survive a failure of  the

TCP接続が失敗を乗り切ることができるべきである十分

route.

発送します。

     3.  Host Algorithm for Fault Recovery

3. 欠点回復のためのホストアルゴリズム

     Since  the gateways always attempt to have a consistent and correct

ゲートウェイが、いつもaを一貫していて正しくするのを試みるので

model of the internetwork topology, the host strategy for fault recovery

インターネットワークトポロジー、欠点回復のためのホスト戦略のモデル

is very simple.  Whenever the host feels that  something  is  wrong,  it

非常に簡単です。 ホストがそれを感じるときはいつも、何か問題がある、それ

asks the gateway for advice, and, assuming the advice is forthcoming, it

そして、アドバイスが用意されていると仮定しながらアドバイスを求めてゲートウェイを尋ねる、それ

believes  the  advice  completely.  The advice will be wrong only during

アドバイスを完全に信じています。 悪事が唯一であったなら、アドバイスはそうするでしょう。

the transient  period  of  negotiation,  which  immediately  follows  an

一時的な期間の交渉。(その交渉はすぐに、続きます)。

outage, but will otherwise be reliably correct.

そうでなければ、確かに正しいのを除いた供給停止。

     In  fact,  it  is  never  necessary  for a host to explicitly ask a

事実上、ホストが明らかにaを尋ねるのは決して必要ではありません。

gateway for advice, because the gateway will provide it as  appropriate.

アドバイスを求めるゲートウェイが適宜それを提供するのでゲートウェイ。

When  a  host  sends  a datagram to some distant net, the host should be

ホストが何らかの遠方のネットにデータグラムを送るとき、ホストは送るべきです。

prepared to receive back either  of  two  advisory  messages  which  the

受信し返すように準備されて、2状況報告のどちらかがどれを通信させるか。

gateway  may  send.    The  ICMP  "redirect"  message indicates that the

ゲートウェイは発信するかもしれません。 ICMPの「再直接」のメッセージはそれを示します。

gateway to which the host sent the  datagram  is  not  longer  the  best

ホストがデータグラムを送ったゲートウェイは最もよく長くはありません。

gateway  to  reach the net in question.  The gateway will have forwarded

問題のネットに達するゲートウェイ。 ゲートウェイは進めた状態で持つでしょう。

the datagram, but the host should revise its routing  table  to  have  a

しかし、データグラム、ホストは、aを持つために経路指定テーブルを改訂するべきです。

different  immediate  address  for  this  net.    The  ICMP "destination

                                   3

このネットのための異なった即値アドレス。 ICMP「目的地3」

unreachable"  message  indicates  that  as  a result of an outage, it is

「手の届かない」メッセージは、供給停止の結果、それがそうであることを示します。

currently impossible to reach the addressed net or host in  any  manner.

どんな方法でも記述されたネットかホストに届くのは現在、不可能です。

On  receipt  of  this  message, a host can either abandon the connection

このメッセージを受け取り次第、ホストは接続を捨てることができます。

immediately without any further retransmission, or resend slowly to  see

すぐにいずれなしでも「再-トランスミッション」を促進するか、または見るのをゆっくり再送します。

if the fault is corrected in reasonable time.

欠点が妥当な時間で修正されるなら。

     If  a  host  could assume that these two ICMP messages would always

ホストが、これらの2つのICMPメッセージがいつもそうすると仮定できるなら

arrive when something was amiss in the network, then no other action  on

到着、いつへのものはネットワークで何か不都合であり、その時は他の動作でないか。

the  part  of the host would be required in order maintain its tables in

ホストの部分が、中でテーブルを維持するのに必要でしょう。

an optimal condition.  Unfortunately, there are two circumstances  under

最適条件。 残念ながら、下である2つの事情があります。

which  the  messages  will  not  arrive  properly.    First,  during the

メッセージが望んでいるものは適切に到着しません。 最初に

transient following a failure, error messages may  arrive  that  do  not

一時的である、失敗に続いて、そうしないエラーメッセージは到着するかもしれません。

correctly  represent  the  state of the world.  Thus, hosts must take an

正しく世界の状態を表してください。 したがって、ホストは取らなければなりません。

isolated error message with some scepticism.  (This transient period  is

何らかの懐疑論がある孤立しているエラーメッセージ。 (この一時的な期間はそうです。

discussed  more  fully  below.)    Second,  if the host has been sending

以下で、より完全に議論します。) 2番目ホストが発信して、

datagrams to a particular gateway, and that gateway itself crashes, then

特定のゲートウェイ、およびそのゲートウェイ自体へのデータグラム、そして、クラッシュします。

all the other gateways in the internet will  reconstruct  the  topology,

インターネットにおける他のすべてのゲートウェイがトポロジーを再建するでしょう。

but  the  gateway  in  question will still be down, and therefore cannot

したがってであることができるそして、しかし、問題のゲートウェイがまだ下がっている。

provide any advice back to the host.  As long as the host  continues  to

あらゆるアドバイスをホストに提供して戻してください。 ホストが、続けている限り

direct  datagrams at this dead gateway, the datagrams will simply vanish

この停止ゲートウェイにデータグラムを向けてください、そして、データグラムは単に消え失せるでしょう。

off the face of the earth, and nothing will come back in return.   Hosts

球全体、および意志が入って戻させないものは何ではでも、戻ってください。 ホスト

must detect this failure.

この失敗を検出しなければなりません。

     If some gateway many hops away fails, this is not of concern to the

遠くの幾つかのゲートウェイ多くのホップであるなら、やり損ないであり、これは関心のものではありません。

host, for then the discovery of the failure is the responsibility of the

次に、失敗の発見が責任であるので、接待します。

immediate  neighbor gateways, which will perform this action in a manner

すぐ隣の人ゲートウェイ。(そのゲートウェイは方法でこの動作を実行するでしょう)。

invisible to the host.  The  problem  only  arises  if  the  very  first

                                   4

ホストにとって、目に見えません。 問題はまさしくその最初の4である場合にだけ起こります。

gateway, the one to which the host is immediately sending the datagrams,

ゲートウェイ、ホストがすぐにデータグラムを送るもの

fails.   We thus identify one single task which the host must perform as

失敗します。 その結果、私たちはホストが働かなければならない1つのシングルタスクを特定します。

its part of fault isolation in the internet:  the  host  must  use  some

インターネットにおける欠点孤立の一部: ホストはいくつかを使用しなければなりません。

strategy  to  detect  that a gateway to which it is sending datagrams is

検出するそれがデータグラムを送るゲートウェイがそうである戦略

dead.

死ぬ。

     Let us  assume  for  the  moment  that  the  host  implements  some

さしあたり、ホストがいくつかを実行すると仮定しましょう。

algorithm  to  detect  failed  gateways; we will return later to discuss

検出するアルゴリズムはゲートウェイに失敗しました。 私たちは議論するのにおいて後であることの状態で戻るつもりです。

what this algorithm might be.  First, let  us  consider  what  the  host

このアルゴリズムは何であるかもしれませんか? まず最初になにかを考えようか、ホスト

should  do  when it has determined that a gateway is down. In fact, with

それが、ゲートウェイが下がっていることを決定したときにはそうするべきであってください。 事実上

the exception of one small problem, the action the host should  take  is

1つの小さい問題の例外、ホストが取るべきである行動はそうです。

extremely  simple.    The host should select some other gateway, and try

非常に簡単です。 ホストは、ある他のゲートウェイを選択して、試みるべきです。

sending the datagram to it.  Assuming that  gateway  is  up,  this  will

データグラムをそれに送ります。 ゲートウェイが上がっていると仮定すると、これは仮定するでしょう。

either  produce  correct  results, or some ICMP advice.  Since we assume

どちらかが正しい結果、または何らかのICMPアドバイスを生みます。 以来、私たちは仮定します。

that, ignoring temporary periods immediately following  an  outage,  any

いくらかすぐに供給停止に続いて、一時的な期間を無視するそれ

gateway  is capable of giving correct advice, once the host has received

ホストがいったん受信すると、ゲートウェイは正しいアドバイスを与えることができます。

advice from any gateway, that host is in as good a condition as  it  can

どんなゲートウェイからのホストがそれのように同じくらい良い状態でいるというアドバイスもそうすることができます。

hope to be.

望んでください。。

     There is always the unpleasant possibility that when the host tries

ホストであるときに試みる不快な可能性がいつもあります。

a different gateway, that gateway too will be down.  Therefore, whatever

異なったゲートウェイであり、そのゲートウェイも下がるでしょう。 したがって、何でも?

algorithm  the  host  uses to detect a dead gateway must continuously be

ホストが停止ゲートウェイを検出するのに使用するアルゴリズムが絶え間なくあるに違いありません。

applied, as the host tries every gateway in turn that it knows about.

ホストが順番にあらゆるゲートウェイを試すので適用される、それは知っています。

     The only difficult part of this algorithm is to specify  the  means

このアルゴリズムの唯一の難しい部分は手段を指定することです。

by which the host maintains the table of all of the gateways to which it

ホストがゲートウェイのすべてのテーブルをどれに維持するか、どれ、それ

has  immediate  access.    Currently,  the specification of the internet

即座のアクセサリーを持っています。 現在のインターネットの仕様

protocol does not architect any message by which a host can  ask  to  be

                                   5

プロトコルはホストが5であると尋ねることができるどんなメッセージもどんな建築家にもしません。

supplied  with  such a table.  The reason is that different networks may

そのようなテーブルを供給します。 理由は異なったネットワークがそうするかもしれないということです。

provide very different mechanisms by which this table can be filled  in.

このテーブルに記入できる非常に異なったメカニズムを提供してください。

For  example,  if  the  net is a broadcast net, such as an ethernet or a

例えば、ネットが放送であるなら、イーサネットやaのように、網状になってください。

ringnet, every gateway may simply broadcast such a table  from  time  to

ringnetに、あらゆるゲートウェイが単に時間からのそのようなテーブルを放送するかもしれません。

time,  and  the  host  need do nothing but listen to obtain the required

必要性が必要を得るために聴くだけである時間、およびホスト

information.  Alternatively, the network may provide  the  mechanism  of

情報。 あるいはまた、ネットワークはメカニズムを提供するかもしれません。

logical  addressing,  by  which  a whole set of machines can be provided

論理的なアドレシング。(そのアドレシングで1つの全体集合のマシンを提供できます)。

with a single group  address,  to  which  a  request  can  be  sent  for

ただ一つのグループアドレスで。(それに要求を注文できます)。

assistance.   Failing those two schemes, the host can build up its table

支援。 それらの2つの計画に失敗する場合、ホストはテーブルを確立できます。

of neighbor gateways by remembering all the gateways from which  it  has

それがそうしたすべてのゲートウェイを覚えているのによる隣人ゲートウェイについて

ever received a message.  Finally, in certain cases, it may be necessary

今までに、メッセージは受信されました。 ある場合には、最終的に、それが必要であるかもしれません。

for  this  table,  or  at  least the initial entries in the table, to be

このテーブル、または少なくともテーブルの初期のエントリーに

constructed manually by a manager or operator at the  site.    In  cases

サイトのマネージャかオペレータによって手動で組み立てられます。 場合で

where  the  network  in question provides absolutely no support for this

問題のネットワークがこのサポートを全く絶対に提供しないところ

kind of host query, at least some manual intervention will  be  required

質問をちょっと主催してください、そして、少なくとも何らかの手動の介入が必要でしょう。

to  get  started,  so  that  the  host  can  find out about at least one

ホストが少なくとも1時頃に見つけることができるように開始するために

gateway.

ゲートウェイ。

     4.  Host Algorithms for Fault Isolation

4. 欠点孤立のためのホストアルゴリズム

     We now return to the question raised above.  What  strategy  should

私たちはもう、上に引き起こされた疑問に戻ります。 どんな戦略はそうするべきであるか。

the  host use to detect that it is talking to a dead gateway, so that it

したがって、それが停止ゲートウェイと話している検出するホスト使用、それ、それ

can know to switch to some other gateway in the list. In fact, there are

リストのある他のゲートウェイに切り替わるのを知ることができます。 事実上、あります。

several algorithms which can be used.   All  are  reasonably  simple  to

使用できるいくつかのアルゴリズム。 すべてが合理的に簡単です。

implement, but they have very different implications for the overhead on

しかし、道具、彼らはオーバーヘッドのための非常に異なった意味をオンに持っています。

the  host, the gateway, and the network.  Thus, to a certain extent, the

ホスト、ゲートウェイ、およびネットワーク。 このようにして、そして、ある程度

algorithm picked must depend on the details of the network  and  of  the

そして選ばれたアルゴリズムがネットワークの細部によらなければならない。

host.

                                   6

接待します。 6

1.  NETWORK LEVEL DETECTION

1. 平らな検出をネットワークでつないでください。

     Many  networks,  particularly  the  Arpanet,  perform precisely the

多くのネットワーク(特にArpanet)が正確に働きます。

required function internal to the network.  If a host sends  a  datagram

ネットワークへの内部の必要な機能。 ホストがデータグラムを送るなら

to  a dead gateway on the Arpanet, the network will return a "host dead"

Arpanetの上の停止ゲートウェイに、ネットワークは「死ぬホスト」を返すでしょう。

message, which is precisely the information the host needs  to  know  in

メッセージ。(そのメッセージは正確に知るホストが必要とする情報です)。

order  to  switch  to  another  gateway.   Some early implementations of

もう1門に切り替わるには、注文してください。 いくつかの早めの実現

Internet on  the  Arpanet  threw  these  messages  away.    That  is  an

Arpanetの上のインターネットはこれらのメッセージを無駄にしました。 すなわち

exceedingly poor idea.

きわめて劣った考え。

2.  CONTINUOUS POLLING

2. 連続した世論調査

     The  ICMP  protocol  provides an echo mechanism by which a host may

ICMPプロトコルはホストがそうするかもしれないエコーメカニズムを提供します。

solicit a response from a gateway.    A  host  could  simply  send  this

ゲートウェイから応答に請求してください。 ホストは単にこれを送ることができました。

message  at  a  reasonable  rate, to assure itself continuously that the

妥当なレートで通信して、絶え間なくそれ自体を保証してください、それ

gateway was still up.  This works, but, since the message must  be  sent

ゲートウェイはまだ上がっていました。 しかし、これは、メッセージを送らなければならないので、働いています。

fairly  often  to  detect  a fault in a reasonable time, it can imply an

しばしば中に欠点を検出するために、公正に、それは、妥当なaが調節されるのを含意できます。

unbearable overhead on the host itself, the network,  and  the  gateway.

ホスト自身、ネットワーク、およびゲートウェイの上の耐え難いオーバーヘッド。

This  strategy  is  prohibited  except  where  a  specific  analysis has

特定の分析が禁止したのを除いて、この戦略は禁止されています。

indicated that the overhead is tolerable.

オーバーヘッドが許容できるのを示しました。

3.  TRIGGERED POLLING

3. 引き起こされた世論調査

     If the use of polling could be restricted to only those times  when

世論調査の使用がそれらの回だけに制限される場合がある、いつ

something  seemed  to  be  wrong,  then  the overhead would be bearable.

何かが間違っているように思えて、次に、オーバーヘッドは辛抱できるでしょう。

Provided that one can get the proper  advice  from  one's  higher  level

1つが人の、より高いレベルから適切なアドバイスを得ることができれば

protocols,  it  is  possible to implement such a strategy.  For example,

プロトコルであり、そのような戦略を実行するのは可能です。 例えば

one could program the TCP level so  that  whenever  it  retransmitted  a

                                   7

人がプログラムを作ることができた、したがって、a7を再送したときはいつも、TCPはそれを平らにします。

segment  more  than  once,  it  sent  a  hint down to the IP layer which

セグメントはどれをIPまで層にするか一度、それがaを送った以上が、手がかりである。

triggered polling.  This strategy does not have excessive overhead,  but

世論調査の引き金となりました。 しかし、この戦略には、過度のオーバーヘッドがありません。

does  have  the problem that the host may be somewhat slow to respond to

ホストは応じるのがいくらか遅いかもしれないという問題を持っています。

an error, since only after polling has started will the host be able  to

誤り、世論調査が始まる後以来だけ、ホストはできるでしょう。

confirm  that  something  has  gone wrong, and by then the TCP above may

何かが悪さ、および上のTCPがそうするその時までに行ったと確認してください。

have already timed out.

外で既に時間があってください。

     Both forms of polling suffer from a minor flaw.  Hosts as  well  as

世論調査の両方のフォームは小さな欠陥が欠点です。 ホスト

gateways respond to ICMP echo messages.  Thus, polling cannot be used to

ゲートウェイはICMPエコーメッセージに応じます。 その結果、世論調査は使用されているはずがありません。

detect  the  error  that  a  foreign  address thought to be a gateway is

ゲートウェイであると考えられた外国アドレスがそうである誤りを検出してください。

actually a host.  Such a confusion can arise if the  physical  addresses

実際にホスト。 そのような混乱は物理アドレスであるなら起こることができます。

of machines are rearranged.

マシンは再配列されます。

4.  TRIGGERED RESELECTION

4. 引き起こされたRESELECTION

     There  is a strategy which makes use of a hint from a higher level,

より高いレベルからヒントを利用する戦略があります。

as did the previous  strategy,  but  which  avoids  polling  altogether.

しかし、前の戦略、全体で投票するのを避けるもののように。

Whenever  a  higher  level  complains  that  the  service  seems  to  be

サービスが見えるより高いレベルに不平を言うときはいつも、いてください。

defective, the Internet layer can pick the next gateway from the list of

不良、層がリストからの隣のゲートウェイを選ぶことができるインターネット

available gateways, and switch to it.  Assuming that this gateway is up,

利用可能なゲートウェイ、およびそれへのスイッチ。 このゲートウェイが上がっていると仮定します。

no real harm can come of this decision, even if it was  wrong,  for  the

それが間違ったとしても、どんな本当の害もこの決定から起こることができません。

worst that will happen is a redirect message which instructs the host to

起こる最悪はホストを命令する再直接のメッセージです。

return to the gateway originally being used.  If, on the other hand, the

元々使用されるゲートウェイに戻ってください。 他方では

original  gateway  was indeed down, then this immediately provides a new

本当に、オリジナルのゲートウェイが下がっていた、そして、これはすぐに、新しい状態でaを提供します。

route, so the period of time until recovery is  shortened.    This  last

回復までの期間が短くされて、発送します。 この最終

strategy  seems  particularly clever, and is probably the most generally

一般に、戦略は、特に賢明に思えて、たぶん最も多いです。

suitable for those cases where the network itself does not provide fault

ネットワーク自体が欠点を提供しないそれらのケースに適しています。

isolation.  (Regretably, I have forgotten who suggested this idea to me.

孤立。 (Regretablyに、私は、だれがこの考えを私に勧めたかを忘れました。

It is not my invention.)

                                   8

それは私の発明ではありません。) 8

     5.  Higher Level Fault Detection

5. より高い平らな欠点検出

     The  previous  discussion  has  concentrated on fault detection and

そして前の議論が欠点検出に集中した。

recovery at the IP layer.  This section considers what the higher layers

IP層での回復。 このセクションは、より高いのが何を層にするかを考えます。

such as TCP should do.

TCPとしてのそのようなものはするべきです。

     TCP has a single fault recovery action; it repeatedly retransmits a

TCPには、ただ一つの欠点回復動作があります。 それは繰り返してaを再送します。

segment until either it gets an acknowledgement or its connection  timer

それまでのセグメントは承認かその接続タイマを手に入れます。

expires.    As discussed above, it may use retransmission as an event to

期限が切れます。 上で議論するように、それは出来事として「再-トランスミッション」を使用するかもしれません。

trigger a request for fault recovery to the IP  layer.    In  the  other

IP層への欠点回復を求める要求の引き金となってください。 もう片方で

direction,  information  may  flow  up from IP, reporting such things as

指示、情報はIPから流れるかもしれなくて、報告はそのようなものです。

ICMP  Destination  Unreachable  or  error  messages  from  the  attached

付属からのICMP Destination Unreachableかエラーメッセージ

network.    The  only  subtle  question about TCP and faults is what TCP

ネットワークでつなぎます。 TCPと欠点に関する唯一の微妙な質問がそうである、何というTCP

should do when such an error message arrives  or  its  connection  timer

そのようなエラーメッセージがいつ到着するか、そして、その接続タイマをするべきです。

expires.

期限が切れます。

     The  TCP  specification discusses the timer.  In the description of

TCP仕様はタイマについて議論します。 記述

the open call, the timeout is described as an optional  value  that  the

オープンコールであり、タイムアウトが任意の値として記述されている、それ

client  of  TCP  may  specify; if any segment remains unacknowledged for

TCPのクライアントは指定するかもしれません。 何かセグメントが認められないままで残っているなら

this period, TCP should abort the  connection.    The  default  for  the

この期間であり、TCPは接続を中止するはずです。 デフォルトとします。

timeout  is  30 seconds.  Early TCPs were often implemented with a fixed

タイムアウトは30秒です。 早く、aが修理されている状態で、TCPsはしばしば実行されました。

timeout interval, but this  did  not  work  well  in  practice,  as  the

しかし、タイムアウト間隔、これは実際にはうまくいきませんでした。

following discussion may suggest.

以下の考察は示されるかもしれません。

     Clients  of  TCP can be divided into two classes:  those running on

TCPのクライアントを2つのクラスに分割できます: 走られるもの

immediate behalf of a human, such as  Telnet,  and  those  supporting  a

aを支持するTelnet、およびそれらとして人間の、そして、そのようなaの即座の利益

program, such as a mail sender.  Humans require a sophisticated response

メール送付者のように、プログラムを作ってください。 人間は洗練された応答を必要とします。

to  errors.    Depending  on  exactly  what went wrong, they may want to

                                   9

誤りに。 まさに何が支障をきたしたかによって、彼らは9まで欲しいかもしれません。

abandon the connection at once, or wait for a long time to see if things

すぐに、接続を捨てるか、またはいろいろなことであるなら長い間、見るのを待ってください。

get  better.   Programs do not have this human impatience, but also lack

回復してください。 プログラムには、この人間のいらだちではなく、不足もあります。

the power to make complex decisions based on details of the exact  error

正確な誤りの詳細に基づく複雑な決定をするパワー

condition.  For them, a simple timeout is reasonable.

条件とします。 それらに関しては、簡単なタイムアウトは妥当です。

     Based  on these considerations, at least two modes of operation are

これらの問題に基づいて、少なくとも2つの運転モードがそうです。

needed in TCP.  One,  for  programs,  abandons  the  connection  without

TCPでは、必要です。 プログラムのために、1つは接続を捨てます。

exception  if  the  TCP  timer  expires.    The other mode, suitable for

例外はTCPタイマであるなら期限が切れます。 もう片方のモードで、適当です。

people, never abandons the connection on its own initiative, but reports

民族、それ自身のイニシアチブに接続を決して捨てませんが、報告します。

to the layer above when the timer expires.  Thus, the human user can see

タイマが期限が切れる時の上の層に。 したがって、人間のユーザは見ることができます。

error messages coming from all the relevant layers, TCP  and  ICMP,  and

そしてすべての関連層、TCP、およびICMPから来るエラーメッセージ。

can request TCP to abort as appropriate.  This second mode requires that

適宜中止になるようTCPに要求できます。 この2番目のモードはそれを必要とします。

TCP  be  able to send an asynchronous message up to its client to report

TCP、非同期なメッセージを報告するクライアントまで送ることができてください。

the timeout, and it requires  that  error  messages  arriving  at  lower

そして、タイムアウト、それは、より低くそのエラーメッセージ到着を必要とします。

layers similarly flow up through TCP.

層はTCPを通して同様に流れます。

     At  levels  above TCP, fault detection is also required.  Either of

また、TCPの上のレベルでは、欠点検出が必要です。 どちらか

the following can happen.  First, the foreign client of  TCP  can  fail,

以下は起こることができます。 まず最初に、TCPの外国人のクライアントは失敗できます。

even  though TCP is still running, so data is still acknowledged and the

そしてTCPがまだ走っていますが、したがって、データがまだ承認されている。

timer never expires.  Alternatively, the communication  path  can  fail,

タイマは決して期限が切れません。 あるいはまた、通信路は失敗できます。

without the TCP timer going off, because the local client has no data to

地元のクライアントにはデータが全くないので発射されるTCPタイマ

send.  Both of these have caused trouble.

発信してください。 これらの両方が問題を起こしました。

     Sending  mail  provides an example of the first case.  When sending

送付郵便配達人は最初のケースに関する例を提供します。 発信します。

mail using SMTP, there is an SMTP level acknowledgement that is returned

メールがSMTPを使用して、返されるSMTPの平らな承認があります。

when a piece of mail is successfully  delivered.    Several  early  mail

1つのメールが首尾よく提供されるとき。 いくつかの早めのメール

receiving programs would crash just at the point where they had received

プログラムを受け取るのはまさしくそれらが受信したポイントでダウンするでしょう。

all of the mail text (so TCP did not detect a timeout due to outstanding

                                   10

メールテキストのすべて、(それで、TCPは傑出している10によるタイムアウトを検出しませんでした。

unacknowledged  data)  but  before the mail was acknowledged at the SMTP

不承認のデータ)、メールはSMTPで承認されました。

level.  This failure would cause early mail senders to wait forever  for

レベル。 この失敗はいつまでも待つ送付者を早めのメールに引き起こすでしょう。

the  SMTP level acknowledgement.  The obvious cure was to set a timer at

SMTPは承認を平らにします。 療法がタイマを設定することになっていた明白

the SMTP level, but the first attempt to do this did not work, for there

仕事ではなく、そこへのしかし、レベル、これをする最初の試みがそうするSMTP

was no simple way to  select  the  timer  interval.    If  the  interval

どんな簡単な道もタイマ間隔を選択することになっていませんでしたか? 間隔です。

selected  was  short,  it  expired  in normal operational when sending a

選択、aを送るとき、急に、標準で操作上で期限が切れたということでした。

large file to a slow host.  An interval of many minutes  was  needed  to

遅いホストへの大きいファイル。 数分が必要であった多くの間隔

prevent  false timeouts, but that meant that failures were detected only

検出されていた状態でしかし、誤ったタイムアウト、意味された失敗がいたそれを防いでください、唯一

very slowly.  The current solution in  several  mailers  is  to  pick  a

非常にゆっくり。 数人の郵送者の現在のソリューションはaを選ぶことです。

timeout interval proportional to the size of the message.

メッセージのサイズに比例しているタイムアウト間隔。

     Server telnet provides an example of the other kind of failure.  It

サーバtelnetはもう片方の種類の失敗に関する例を提供します。 それ

can  easily  happen that the communications link can fail while there is

容易に起こることができる、コミュニケーションリンクはある間に失敗できます。

no traffic flowing, perhaps because the user is thinking.    Eventually,

ユーザが恐らく考えているので流れるトラフィックがありません。 結局

the  user will attempt to type something, at which time he will discover

ユーザは、彼が発見するどの時に何かをタイプするかを試みるでしょう。

that the connection is dead and abort it.   But  the  host  end  of  the

接続は、死んで、それを中止します。 しかし、ホストは終わります。

connection,  having  nothing  to send, will not discover anything wrong,

何も送るものを持っていなくて、接続は間違ったものは何も発見しないでしょう。

and will remain waiting forever.  In some systems there is no way for  a

そして、いつまでも待ちながら残るために望んでください。いくつかのシステムには、aのための方法が全くありません。

user  in  a  different  process  to  destroy or take over such a hanging

そのような絞首刑の上で破壊するか、または取る異なったプロセスのユーザ

process, so there is no way to recover.

回復する方法が全くないように、処理してください。

     One solution to this would be to have the host server telnet  query

これへの1つのソリューションはホストサーバtelnet質問を持つだろうことです。

the  user  end now and then, to see if it is still up.  (Telnet does not

ユーザは、それがまだ上がっているかどうか確認するために時折終わります。 (telnetはそうしません。

have an explicit query  feature,  but  the  host  could  negotiate  some

明白な質問機能を持ちなさい、ただし、ホストはいくつかを交渉できました。

unimportant   option,   which   should   produce   either  agreement  or

または重要でないオプション。(それは、協定を作成するべきです)。

disagreement in  return.)    The  only  problem  with  this  is  that  a

リターンにおける不一致。) これに関する唯一の問題がそのaです。

reasonable  sample interval, if applied to every user on a large system,

                                   11

大規模システム、11のすべてのユーザに間隔であって、適用されたかなり良いサンプル

can  generate  an unacceptable amount of traffic and system overhead.  A

容認できない量のトラフィックとシステムオーバーヘッドを生成することができます。 A

smart server telnet would use  this  query  only  when  something  seems

何かが見える場合にだけ、賢いサーバtelnetはこの質問を使用するでしょう。

wrong, perhaps when there had been no user activity for some time.

悪さ恐らく、しばらくそこの時はユーザ活動ではありませんでした。

     In  both  these  cases, the general conclusion is that client level

これらの場合の両方では、一般的な結論はそのクライアントレベルです。

error detection is needed, and that the details  of  the  mechanism  are

誤り検出が必要です、そして、メカニズムの細部はそうです。

very dependent on the application.  Application programmers must be made

アプリケーションに非常に依存しています。 アプリケーション・プログラマーを作らなければなりません。

aware  of  the  problem  of  failures,  and  must  understand that error

意識する、失敗、および必須の問題をその誤りを理解してください。

detection at the TCP or lower level cannot solve the whole  problem  for

TCPか下側でのレベルが全体の問題を解決できない検出

them.

それら。

     6.  Knowing When to Give Up

6. いつあきらめるかを知っています。

     It  is  not  obvious,  when error messages such as ICMP Destination

ICMP Destinationなどのエラーメッセージであるときに、それは明白ではありません。

Unreachable arrive, whether TCP should  abandon  the  connection.    The

手の届かなさ、TCPが接続を捨てるはずであるか否かに関係なく、到着してください。 The

reason  that  error  messages  are  difficult  to  interpret is that, as

エラーメッセージは解釈するのが難しい理由がそれです。

discussed above, after a failure of a gateway or  network,  there  is  a

ゲートウェイかネットワークの失敗の後に上で議論していて、aがあります。

transient   period   during   which  the  gateways  may  have  incorrect

ゲートウェイが不正確な状態で持っているかもしれない一時的な期間

information,  so  that  irrelevant  or  incorrect  error  messages   may

情報、とてもそんなに無関係の、または、不正確なエラーメッセージはそうするかもしれません。

sometimes  return.   An isolated ICMP Destination Unreachable may arrive

時々戻ってください。 孤立しているICMP Destination Unreachableは到着するかもしれません。

at a host, for example, if a packet is sent during the period  when  the

例えば、ホストでは、aであるなら期間、パケットを送る、いつ

gateways  are  trying  to find a new route.  To abandon a TCP connection

ゲートウェイは新しいルートを見つけようとしています。 TCP接続を捨てるために

based on such a message arriving would be to ignore the valuable feature

そのようなメッセージに基づいて、到着は貴重な特徴を無視するだろうことです。

of the Internet that for many  internal  failures  it  reconstructs  its

インターネット、それが再建する多くの内部の失敗のためのそれ、それ

function without any disruption of the end points.

終わりの少しも分裂のない機能は指します。

     But  if failure messages do not imply a failure, what are they for?

しかし、失敗メッセージが失敗を含意しないなら、それらは何のためのものですか?

In fact, error messages serve several important  purposes.    First,  if

                                   12

事実上、エラーメッセージはいくつかの重要な目的に役立ちます。 1番目12であり

they  arrive  in response to opening a new connection, they probably are

新しい接続を開くことに対応してそれらは到着して、彼らはたぶんいます。

caused by opening the connection improperly  (e.g.,  to  a  non-existent

不適切に接続を開くことによって引き起こされる、(例えば、aに実在しません

address)  rather  than  by  a  transient  network failure.  Second, they

アドレス)、むしろ、一時的なネットワーク失敗より。 2番目に、それら

provide valuable information, after the TCP timeout has occurred, as  to

TCPタイムアウトが起こった後に貴重な情報を提供します。

the  probable  cause of the failure.  Finally, certain messages, such as

失敗の推定原因。 最終的にあるメッセージで、あれほどです。

ICMP Parameter Problem, imply a possible  implementation  problem.    In

ICMP Parameter Problem、可能な実装問題を含意してください。 コネ

general, error messages give valuable information about what went wrong,

一般、エラーメッセージは何が支障をきたしたかに関する貴重な情報を与えます。

but  are  not  to  be  taken as absolutely reliable.  A general alerting

しかし、絶対に信頼できるとして取ってはいけなくなってください。 一般的な警告

mechanism, such as the TCP timeout  discussed  above,  provides  a  good

上で議論したTCPタイムアウトなどのメカニズムは利益を提供します。

indication  that  whatever  is wrong is a serious condition, but without

間違ったことなら何でも重態であるという指示だけ

the advisory messages to augment the timer, there  is  no  way  for  the

タイマを増大させる顧問メッセージであり、道が全くありません。

client  to  know  how  to  respond to the error.  The combination of the

誤りに応じる方法を知るクライアント。 組み合わせ

timer and the advice from the error messages provide a reasonable set of

タイマとエラーメッセージからのアドバイスは設定していた状態で妥当なaを提供します。

facts for the client layer to have.  It is important that error messages

クライアント層にはある事実。 それが重要である、そのエラーメッセージ

from all layers be passed up to  the  client  module  in  a  useful  and

そしてすべての層から、aを役に立った状態でクライアントモジュールまで通ってください。

consistent way.

一貫した道。

-------

-------