RFC996 日本語訳
0996 Statistics server. D.L. Mills. February 1987. (Format: TXT=6127 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group D.L. Mills Request for Comments: 996 University of Delaware February 1987
L.工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 996 デラウエア大学1987年2月
Statistics Server
統計サーバ
STATUS OF THIS MEMO
このメモの状態
This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host. Distribution of this memo is unlimited.
このRFCはARPAインターネットコミュニティの規格を指定します。 DARPAインターネットのリモート統計モニターが施設であると実装するのを選ぶホストとゲートウェイは、モニターしているセンターかデバッグホストへの要求に統計データを送るのにこのプロトコルを使用するかもしれません。 このメモの分配は無制限です。
DISCUSSION
議論
Many host and gateway implementations include a facility which records traffic statistics, such as packet counters, error counters and significant event counters for debugging and performance evluation. Simple data-access and formatting programs can be used to display these statistics along with the status of connections, etc. Several operating systems, including the various Unix systems and Fuzzball systems, already provide extensive facilities to capture and display these data for local users and/or operators.
多くのホストとゲートウェイ実装がデバッグと性能evluationのための誤りがパケットカウンタなどのようにそれの記録トラフィック統計を打ち返す施設と重大な行事カウンタを含んでいます。 接続などの状態に伴うこれらの統計を表示するのに簡単なデータ・アクセスとフォーマット・プログラムを使用できます。 様々なUnixシステムとFuzzballシステムを含む数個のオペレーティングシステムが、地元のユーザ、そして/または、オペレータのためにこれらのデータを得て、表示するために既に大規模な施設を提供します。
In many instances it is highly useful to observe statistics data on remote hosts and gateways from a monitoring center or debugging host. Indeed, several protocols have been implemented and used expressly for this purpose [1-6]. In many cases the data can be retrieved using conventional services such as remote login or even file transfer. However, use of these heavyweight mechanisms is awkward and intrusive if conducted on a regular, frequent basis and may involve substantial intrusion in the operating system if retrofitted to existing systems.
多くのインスタンスでは、モニターしているセンターかデバッグホストからリモートホストとゲートウェイに関する統計データを観測するのは非常に役に立ちます。 本当に、いくつかのプロトコルが、この目的[1-6]に明白に実装されて、使用されました。 多くの場合、リモート・ログインかファイル転送などさえの従来のサービスを利用することでデータを検索できます。 しかしながら、これらのヘビー級のメカニズムの使用は、通常の、そして、頻繁なベースで行われるなら、無器用であって、押しつけがましく、既存のシステムに改装されるなら、かなりの侵入にオペレーティングシステムにかかわるかもしれません。
The Statistics Server (STATSRV) protocol is intended as a lightweight mechanism similar in spirit to NETSTAT [7] and complementary to it. STATSRV is designed to capture statistics data with minimal intrusion on existing systems or networks. It is intended for use with existing hosts and gateways primarily for casual monitoring and debugging purposes. It is not intended as a full-function monitoring protocol [1,5,6] providing detailed, standardized reports suitable for machine analysis, for example, but could be useful in exploratory development leading to enduring systems of this type.
Statistics Server(STATSRV)プロトコルは、精神において同様の軽量のメカニズムとしてNETSTAT[7]に意図していてそれを補足しています。 STATSRVは、既存のシステムかネットワークへの最小量の侵入で統計がデータであるとキャプチャするように設計されています。 それは既存のホストとゲートウェイによる主としてカジュアルなモニターと目的をデバッグする使用のために意図します。 それは、詳しく述べられるなら完全な機能のモニターしているプロトコル[1、5、6]として意図しませんが、例えば、マシン分析に適したレポートを標準化しますが、このタイプのシステムに耐えるのに通じる踏査の開発で役に立つかもしれません。
The STATSRV model is based on the native host command language used for statistics monitoring and display. The client sends a null- terminated ASCII command to the server, which then responds with a null-terminated ASCII response suitable for a printer or CRT display. Although in principle STATSRV could be used over TCP, it is less intrusive and more efficient to use it over UDP. In the case of UDP,
STATSRVモデルは統計モニターとディスプレイに使用される固有のホストコマンド言語に基づいています。 クライアントはヌルの終えられたASCIIコマンドをサーバに送ります。(それは、その時、プリンタかCRTディスプレイに適当なヌルで終えられたASCII応答で反応します)。 原則としてTCPの上でSTATSRVを使用できましたが、UDPの上でそれを使用するのは、より押しつけがましくなくて、より効率的です。 UDPの場合で
D. L. Mills [Page 1] RFC 996 February 1987
D。 L。 1987年2月にRFC996を製粉します[1ページ]。
commands and responses must fit into a single 576-octet IP datagram. In both UDP and TCP the assigned port number is 133 (decimal).
コマンドと応答は単一の576八重奏のIPデータグラムに収まらなければなりません。 UDPとTCPの両方では、割り当てられたポートナンバーは133(10進)です。
As is conventional in other lightweight services of this type (NETSTAT, FINGER, etc.), there is no provision for access control or authentication in STATSRV. If necessary, each command could include a password or other mechanism to discourage casual abuse.
そのままで、このタイプ(NETSTAT、FINGERなど)の他の軽量のサービスで従来であり、アクセスコントロールか認証への支給が全くSTATSRVにありません。 必要なら、各コマンドは、カジュアルな乱用に水をさしているためにパスワードか他のメカニズムを含むかもしれません。
EXAMPLE
例
The Fuzzball system includes many local commands to display internal data structures, including one that produces the following billboard for each network device, in this case "dm0" on host "udel2.udel.edu":
Fuzzballシステムは内部のデータ構造を表示する多くのローカルのコマンドを含んでいます、それぞれのネットワークデバイスのために以下の掲示板を生産するものを含んでいて、この場合「ホスト"udel2.udel.edu"のdm0":」
Process type: 000027 options: 040000 Subnet: DMV status: 376 hello: 15 timeout: 2000 Foreign address: [192.5.39.87] max size: 576 Input packets 3645 Output packets 3690 bad format 0 ICMP msgs 0 bad checksum 0 Input errors 0 returned 0 Output errors 0 dropped 2 No buffer 0 HELLO msgs 2286 Preempted 0
タイプを処理してください: 000027のオプション: 040000サブネット: DMV状態: 376 こんにちは: 15タイムアウト: 2000年の外国アドレス: [192.5 .39 .87] サイズに最大限にしてください: 0つの3690年の悪い形式0ICMP msgs0の悪いチェックサムInput誤り0が0つのOutput誤り0を返した576の入力パケット3645のOutputパケットは2いいえバッファ0HELLO msgs2286Preempted0を下げました。
The same billboard is returned as a null-terminated ASCII string in a UDP datagram by sending the null-terminated ASCII command "dm0" in a UDP datagram to the host. Similar billboards can be produced for most processes in the system. Unix programs and shell scripts have been built which send commands like these to selected hosts on a periodic basis in order to construct a simple, ad-hoc monitoring facility.
ヌルで終えられたASCIIストリングとしてUDPデータグラムでヌルで終えられたASCIIコマンド「ホストへのUDPデータグラムのdm0"」を送ることによって、同じ掲示板を返します。 システムのほとんどのプロセスのために同様の掲示板を生産できます。 簡単で、臨時のモニターしている施設を構成するために周期的ベースで選択されたホストへのこれらのようなコマンドを送るunixプログラムとシェルスクリプトが組立てられました。
REFERENCES
参照
[1] Flood Page, D.,"Gateway Monitoring Protocol", DARPA Network Working Group Report IEN-131, Bolt Beranek and Newman, February 1980.
[1] ページとD.と「ゲートウェイのモニターしているプロトコル」とDARPAネットワークワーキンググループレポートIEN-131とボルトBeranekとニューマン、1980年2月をあふれさせてください。
[2] Flood Page, D., "The CMCC Terminal Process", DARPA Network Working Group Report IEN-132, Bolt Beranek and Newman, February 1980.
[2] ページとD.と「CMCCの端末のプロセス」とDARPAネットワークワーキンググループレポートIEN-132とボルトBeranekとニューマン、1980年2月をあふれさせてください。
[3] Flood Page, D., "CMCC Performance Measurement Message Formats", DARPA Network Working Group Report IEN-157, Bolt Beranek and Newman, September 1980.
[3] 洪水ページ、D.、「CMCCパフォーマンス測定メッセージ・フォーマット」(DARPAネットワークワーキンググループレポートIEN-157)はBeranekとニューマン(1980年9月)をボルトで締めます。
[4] Jones, R.G., " A Proposal for Simple Measurement Support for Users", DARPA Network Working Group Report IEN-161, University College London, November 1980.
[4] ジョーンズ、R.G.、DARPAはワーキンググループレポートIEN-161、ユニバーシティ・カレッジロンドン1980年11月に「ユーザの簡単な測定サポートのための提案」とネットワークでつなぎます。
D. L. Mills [Page 2] RFC 996 February 1987
D。 L。 1987年2月にRFC996を製粉します[2ページ]。
[5] Littauer, B.M., A.J. Huang and R.M. Hinden," A Host Monitoring Protocol", DARPA Network Working Group Report IEN-197, Bolt Beranek and Newman, September 1981.
Aホストモニターが、「[5] リタウェル、B.M.、A.J.ホアン、およびR.M.Hinden」と議定書の中で述べる、」、DARPAはワーキンググループレポートIEN-197とボルトBeranekとニューマン(1981年9月)をネットワークでつなぎます。
[6] Hinden, R.M.," A Host Monitoring Protocol", DARPA Network Working Group Report RFC-869, BBN Communications Corporation, December 1983.
Aホストモニターが、「[6]Hinden、R.M.」と議定書の中で述べる、」、12月1983、DARPAは作業部会レポートRFC-869、BBNコミュニケーション社をネットワークでつなぎます。
[7] Reynolds, J.K., and J. Postel, "Assigned Numbers", DARPA Network Working Group Report RFC-990, USC Information Sciences Institute, November 1986.
[7] USC情報科学が1986年11月に設けるレイノルズ、J.K.とJ.ポステル、「規定番号」、DARPAネットワークワーキンググループレポートRFC-990。
D. L. Mills [Page 3]
D。 L。 工場[3ページ]
一覧
スポンサーリンク