RFC603 日本語訳

0603 Response to RFC 597: Host status. J.D. Burchfiel. December 1973. (Format: TXT=1482 bytes) (Updates RFC0597) (Updated by RFC0613) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                  J.D. Burchfiel
RFC # 603                                              BBN-TENEX
NIC # 21022                                            31 December, 1973

1973年12月にワーキンググループJ.D.Burchfiel RFC#603BBN-TENEX NIC#21022 31をネットワークでつないでください。

                   Response to RFC # 597: Host Status

RFC#597への応答: ホスト状態

    I have several questions about the November 1973 ARPANET
topographical map:

私には、1973年11月のアルパネット地形図に関するいくつかの質問があります:

    1.  AMES is 4-connected, i.e. four network connections will go down
        if the IMP fails.  Is there some aspiration that IMPs should be
        no more than three connected?

1. エームズが4によって接続されている、すなわち、IMPが失敗すると、4人のネットワーク接続が落ちるでしょう。 3未満が接続されているならIMPsがそうする何らかの切望がありますか?

    2.  The seven IMPS in the Washington area are arranged into a loop.
        This guarantees that local communication can take place even if
        one connection fails, and is probably a worthwhile preparation
        for area routing.  On the other hand, for example, a break
        between MIT-IPC and MIT-MAC will require them to communicate
        through a 12-hop path through Washington.  This can be remedied
        by a short (inexpensive) connection between Harvard and Lincoln
        Labs.  Is there a plan to pull the Boston area, the San
        Francisco area, and the Los Angeles area into loops like the
        Washington area?

2. ワシントン地域の7IMPSが輪にアレンジされます。 これは、1つの接続が失敗してもローカルのコミュニケーションが行われることができるのを保証して、たぶん領域ルーティングのための価値がある準備です。 他方では、例えば、MIT-IPCとMIT-MACの間の中断は、彼らが12ホップの経路を通ってワシントンを通して交信するのを必要とするでしょう。 ハーバードとリンカーンLabsとの背の低い(安価な)接続はこれを治すことができます。 ボストン地区、サンフランシスコの地域、およびロサンゼルスの地域をワシントン地域のような輪に引く計画がありますか?

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.            10/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社10/99]

Burchfiel                                                       [Page 1]

Burchfiel[1ページ]

一覧

 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 

スポンサーリンク

OCTET_LENGTH関数 文字列長をバイト数で求める

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

上に戻る