RFC1187 日本語訳
1187 Bulk Table Retrieval with the SNMP. M.T. Rose, K. McCloghrie,J.R. Davin. October 1990. (Format: TXT=27220 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Rose
Request for Comments: 1187 Performance Systems International, Inc.
K. McCloghrie
Hughes LAN Systems
J. Davin
MIT Laboratory for Computer Science
October 1990
コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: Inc.K.McCloghrieヒューズLANシステムJ.デーヴィンMITコンピュータサイエンス研究所1990年10月の国際の1187個の言語運用機構
Bulk Table Retrieval with the SNMP
SNMPとの大量のテーブル検索
1. Status of this Memo
1. このMemoの状態
This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (SNMP). This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify a standard for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモは、Simple Network Managementプロトコル(SNMP)を使用することで大量のテーブル検索のためのアルゴリズムのおもしろい家族を報告します。 このメモは改良のためにインターネットコミュニティ、要求議論、および提案のためのExperimentalプロトコルについて説明します。 このメモはインターネットコミュニティの規格を指定しません。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Status of this Memo .................................. 1 2. Abstract ............................................. 1 3. Bulk Table Retrieval with the SNMP ................... 2 4. The Pipelined Algorithm .............................. 3 4.1 The Maximum Number of Active Threads ................ 4 4.2 Retransmissions ..................................... 4 4.3 Some Definitions .................................... 4 4.4 Top-Level ........................................... 5 4.5 Wait for Events ..................................... 6 4.6 Finding the Median between two OIDs ................. 8 4.7 Experience with the Pipelined Algorithm ............. 10 4.8 Dynamic Range of Timeout Values ..................... 10 4.9 Incorrect Agent Implementations ..................... 10 5. The Parallel Algorithm ............................... 11 5.1 Experience with the Parallel Algorithm .............. 11 6. Acknowledgements ..................................... 11 7. References ........................................... 12 Security Considerations.................................. 12 Authors' Addresses....................................... 12
1. このMemoの状態… 1 2. 要約… 1 3. SNMPとのテーブル検索を膨らませてください… 2 4. Pipelinedアルゴリズム… 3 4.1 アクティブな糸の最大数… 4 4.2Retransmissions… 4 4.3 いくつかの定義… 4 4.4 トップレベル… 5 4.5 出来事を待ってください… 6 4.6 2OIDsの間のMedianを見つけます… 8 4.7 Pipelinedアルゴリズムの経験… 10 タイムアウト値の4.8ダイナミックレンジ… 10 4.9 不正確なエージェント実現… 10 5. 平行なアルゴリズム… 11 5.1 平行なアルゴリズムの経験… 11 6. 承認… 11 7. 参照… 12 セキュリティ問題… 12人の作者のアドレス… 12
2. Abstract
2. 要約
This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (RFC 1157) [1].
このメモは、Simple Network Managementプロトコル(RFC1157)[1]を使用することで大量のテーブル検索のためのアルゴリズムのおもしろい家族を報告します。
Rose, McCloghrie & Davin [Page 1] RFC 1187 Bulk Table Retrieval with the SNMP October 1990
ローズ、McCloghrie、およびデーヴィン[1ページ]RFC1187は1990年10月にSNMPとのテーブル検索を膨らませます。
The reader is expected to be familiar with both the Simple Network Management Protocol and SNMP's powerful get-next operator. Please send comments to: Marshall T. Rose <mrose@psi.com>.
読者がSimple Network ManagementプロトコルとSNMPの強力な気付いているオペレータの両方によく知られさせると予想されます。 以下のことのためにコメントを送ってください。 マーシャルT. Rose <mrose@psi.com 、gt。
3. Bulk Table Retrieval with the SNMP
3. SNMPとの大量のテーブル検索
Empirical evidence has shown that SNMP's powerful get-next operator is effective for table traversal, particularly when the management station is interested in well-defined subsets of a particular table. There has been some concern that bulk table retrieval can not be efficiently accomplished using the powerful get-next operator. Recent experience suggests otherwise.
実証的証拠は、テーブル縦断に、SNMPの強力な気付いているオペレータが有能であることを示しました、特に管理局が特定のテーブルの明確な部分集合に興味を持っているとき。 強力な気付いているオペレータを使用することで効率的に大量のテーブル検索を実行できないという何らかの関心がありました。 最近の経験は別の方法で示されます。
In the simplest case, using the powerful get-next operator, one can traverse an entire table by retrieving one object at a time. For example, to traverse the entire ipRoutingTable, the management station starts with:
最も簡単な場合では、強力な気付いているオペレータを使用して、1つは、一度に、1個の物を検索することによって、全体のテーブルを横断できます。 例えば、全体のipRoutingTableを横断するために、管理局は以下から始まります。
get-next (ipRouteDest)
気付いてください。(ipRouteDest)
which might return
どれが戻るかもしれませんか。
ipRouteDest.0.0.0.0
ipRouteDest.0.0、.0、.0
The management station then continues invoking the powerful get-next operator, using the value provided by the previous response, e.g.,
そして、管理局は、例えば前の応答で提供された値を使用して、強力な気付いているオペレータを呼び出し続けています。
get-next (ipRouteDest.0.0.0.0)
気付いてください。(ipRouteDest.0.0、.0、.0)
As this sequence continues, each column of the ipRoutingTable can be retrieved, e.g.,
この系列が続くように、例えばipRoutingTableに関する各コラムを検索できます。
get-next (ipRouteDest.192.33.4.0)
気付いてください。(ipRouteDest.192.33、.4、.0)
which might return
どれが戻るかもしれませんか。
ipRouteIfIndex.0.0.0.0
ipRouteIfIndex.0.0、.0、.0
Eventually, a response is returned which is outside the table, e.g.,
結局、テーブルの外に例えばある応答を返します。
get-next (ipRouteMask.192.33.4.0)
気付いてください。(ipRouteMask.192.33、.4、.0)
which might return
どれが戻るかもしれませんか。
ipNetToMediaIfIndex.192.33.4.1
ipNetToMediaIfIndex.192.33、.4、.1
So, using this scheme, O(rows x columns) management operations are required to retrieve the entire table.
それで、この計画を使用して、O(xコラムをこぐ)管理操作が、全体のテーブルを検索するのに必要です。
Rose, McCloghrie & Davin [Page 2] RFC 1187 Bulk Table Retrieval with the SNMP October 1990
ローズ、McCloghrie、およびデーヴィン[2ページ]RFC1187は1990年10月にSNMPとのテーブル検索を膨らませます。
This approach is obviously sub-optimal as the powerful get-next operator can be given several operands. Thus, the first step is to retrieve an entire row of the table with each operation, e.g.,
このアプローチは、強力な気付いているオペレータにいくつかのオペランドを与えることができるので、明らかにサブ最適です。 したがって、第一歩は各操作のときに例えばテーブルの全体の列を検索することです。
get-next (ipRouteDest, ipRouteIfIndex, ..., ipRouteMask)
気付いてください。(ipRouteDest、ipRouteIfIndex、…、ipRouteMask)
which might return
どれが戻るかもしれませんか。
ipRouteDest.0.0.0.0
ipRouteIfIndex.0.0.0.0
ipRouteMask.0.0.0.0
ipRouteDest.0.0.0.0ipRouteIfIndex.0.0.0.0ipRouteMask.0.0、.0、.0
The management station can then continue invoking the powerful get- next operator, using the results of the previous operation as the operands to the next operation. Using this scheme O(rows) management operations are required to retrieve the entire table.
強力を呼び出す次にステーションが続けることができる経営者側は次期オペレータを得ます、オペランドとして次の操作に古い手術痕の結果を使用して。 この計画O(列)を使用して、管理操作が、全体のテーブルを検索するのに必要です。
Some have suggested that this is a weakness of the SNMP, in that O(rows) serial operations is time-expensive. The problem with such arguments however is that implicit emphasis on the word "serial". In fact, there is nothing to prevent a clever management station from invoking the powerful get-next operation several times, each with different operands, in order to achieve parallelism and pipelining in the network. Note that this approach requires no changes in the SNMP, nor does it add any significant burden to the agent.
O(列)直列操作が時間高価であるので、或るものは、これがSNMPの弱点であると示唆しました。 しかしながら、そのような議論に関する問題は「シリーズ」という言葉へのその暗黙の強調です。 事実上、何も賢明な管理局が何度か強力な気付いている操作を呼び出すのを防ぐものがありません、それぞれ異なったオペランドで、ネットワークで平行関係とパイプライン処理を達成するために。 このアプローチがSNMPにおける変化を全く必要としないことに注意してください、そして、それは少しの重要な負担もエージェントに言い足しません。
4. The Pipelined Algorithm
4. Pipelinedアルゴリズム
Let us now consider an algorithm for bulk table retrieval with the SNMP. In the interests of brevity, the "pipelined algorithm" will retrieve only a single column from the table; without loss of generality, the pipelined algorithm can be easily extended to retrieve all columns.
現在、SNMPとの大量のテーブル検索のためのアルゴリズムを考えましょう。 簡潔さのために、「pipelinedアルゴリズム」はテーブルからただ一つのコラムだけに取り戻すでしょう。 一般性の喪失がなければ、すべてのコラムを検索するためにpipelinedアルゴリズムを容易に広げることができます。
The algorithm operates by adopting a multi-threaded approach: each thread generates its own stream of get-next requests and processes the resulting stream of responses. For a given thread, a request will correspond to a different row in the table.
アルゴリズムはマルチスレッド化されたアプローチを取ることによって、作動します: 各糸は、それ自身の気付いている要求のストリームを発生させて、応答の結果として起こる流れを処理します。 与えられた糸に関しては、要求はテーブルの異なった列に対応するでしょう。
Overall retrieval efficiency is improved by being able to keep several transactions in transit, and by having the agent and management station process transactions simultaneously.
総合的な検索効率は、トランジットにおけるいくつかの取引を保つことができて、同時にエージェントと管理局過程取引を持っていることによって、高められます。
The algorithm will adapt itself to varying network conditions and topologies as well as varying loads on the agent. It does this both by varying the number of threads that are active (i.e., the number of transactions that are being processed and in transit) and by varying the retransmission timeout. These parameters are varied based on the
アルゴリズムはエージェントで負荷を変えることと同様に異なったネットワーク状態とtopologiesに慣れるでしょう。 それは、アクティブな糸(すなわち、処理されてトランジット中であることの取引の数)の数を変えて、再送タイムアウトを変えることによって、これをします。 これらのパラメタがベースで変えられる、オン
Rose, McCloghrie & Davin [Page 3] RFC 1187 Bulk Table Retrieval with the SNMP October 1990
ローズ、McCloghrie、およびデーヴィン[3ページ]RFC1187は1990年10月にSNMPとのテーブル検索を膨らませます。
transaction round-trip-time and on the loss/timeout of transactions.
取引往復の時間と取引の損失/タイムアウトに関して。
4.1. The Maximum Number of Active Threads
4.1. アクティブな糸の最大数
One part of the pipelined algorithm which must be dynamic to get best results is the determination of how many threads to have active at a time. With only one thread active, the pipelined algorithm degenerates to the serial algorithm mentioned earlier. With more threads than necessary, there is a danger of overrunning the agent, whose only recourse is to drop requests, which is wasteful. The ideal number is just enough to have the next request arrive at the agent, just as it finishes processing the previous request. This obviously depends on the round-trip time, which not only varies dynamically depending on network topology and traffic-load, but can also be different for different tables in the same agent.
効果が出るためにダイナミックでなければならないpipelinedアルゴリズムの一部が一度にいくつの糸をアクティブにするかに関する決断です。 1個の糸だけがアクティブな状態で、pipelinedアルゴリズムは、より早く言及された連続のアルゴリズムに退化しています。 必要とするより多くの糸で、要求を落とす唯一の償還請求がことであるエージェントをオーバランさせるという無駄な危険があります。 理想的な数は次の要求をエージェントに到着させるようにただ十分です、ちょうど前の要求を処理し終えるように。 これは往復の時間に明らかによります。(それも、異なったテーブルに、また、ダイナミックにネットワーク形態とトラヒック負荷によって、異なるだけではなく、同じエージェントでいろいろである場合があります)。
With too few threads active, the round-trip time barely increases with each increase in the number of active threads; with too many, the round-trip time increases by the amount of time taken by the agent to process one request. The number is dynamically estimated by calculating the round-trip-time divided by the number of active threads; whenever this value takes on a new minimum value, the limit on the number of threads is adjusted to be the number of threads active at the time the corresponding request was sent (plus one to allow for loss of requests).
あまりにわずかな糸がアクティブな状態で、アクティブな糸の数の各増加に従って、往復の時間はほとんど増加しません。 多く過ぎることで、往復の時間は1つの要求を処理するためにエージェントによってかけられた時間までに増加します。 数は往復のアクティブな糸の数が割られた時間について計算することによって、ダイナミックに見積もられています。 この値が新しい最小値を呈するときはいつも、糸の数における限界は、対応する要求が送られた時代(要求の損失で許容するプラス1つ)にアクティブな糸の数になるように調整されます。
4.2. Retransmissions
4.2. Retransmissions
When there are no gateways between the manager and agent, the likelihood of in-order arrival of requests and responses is quite high. At present, the decision to retransmit is based solely on the timeout. One possible optimization is for the manager to remember the order in which requests are sent, and correlate this to incoming responses. If one thread receives a response before another thread which sent an earlier request, then lossage could be assumed, and a retransmission made immediately.
マネージャとエージェントの間にゲートウェイが全くないとき、要求と応答のオーダーへの到達の見込みはかなり高いです。 現在のところ、再送するという決定は唯一タイムアウトに基づいています。 最適化がマネージャが要求が送られるオーダーを覚えていて、入って来る応答にこれを関連させることであることが可能な1つ。 1個の糸が以前の要求を送った別の糸の前に応答を受けるなら、lossageを想定できて、「再-トランスミッション」がすぐに作ったその時です。
4.3. Some Definitions
4.3. いくつかの定義
To begin, let us define a "thread" as some state information kept in the management station which corresponds to a portion of the table to be retrieved. A thread has several bits of information associated with it:
何らかの州の情報が検索されるためにテーブルの一部に対応する管理局に閉じ込めたので、始まるように、「糸」を定義させてください。 糸には、それに関連している情報の数ビットがあります:
(1) the range of SNMP request-ids which this thread can use,
along with the last request-id used;
(1) この糸が使用される最後の要求イドと共に使用できるSNMP要求イドの範囲。
(2) last SNMP message sent, the number of times it has been
最後のSNMPメッセージが送った(2)、それが回数であった
Rose, McCloghrie & Davin [Page 4] RFC 1187 Bulk Table Retrieval with the SNMP October 1990
ローズ、McCloghrie、およびデーヴィン[4ページ]RFC1187は1990年10月にSNMPとのテーブル検索を膨らませます。
(re)sent, the time it was (re)sent;
それを送ったとき(re)、(re)は発信しました。
(3) the inclusive lower-bound and exclusive upper-bound of
the object-instance for the portion of the table that
this thread will retrieve, along with the current
object-instance being used;
(3) この糸が使用される現在の物例と共に検索するテーブルの一部への物例の包括的な下界と排他的な上限。
(4) the number of threads which were active at the time it
was last sent;
(4) それが最後であったことで、アクティブであった糸の数は発信しました。
When a thread is created, it automatically sends a get-next message using its inclusive lower-bound OID. Further, it is placed at the end of the "thread queue".
糸が作成されるとき、それは、包括的な下界OIDを使用することで自動的に気付いているメッセージを送ります。 さらに、「糸の待ち行列」の終わりに置かれます。
Let us also define an OID as a concrete representation of an object identifier which contains two parts:
また、2つの部品を含む物の識別子の具体的な表現とOIDを定義しましょう:
(1) the number of sub-identifiers present, "nelem";
サブ識別子の数が提示する(1)、"nelem"。
(2) the sub-identifiers themselves in an array, "elems",
indexed from 1 up to (and including) "nelem".
(2) アレイのサブ識別子"elems"自体は1つの上から(そして、包含)"nelem"まで索引をつけました。
4.4. Top-Level
4.4. トップレベル
The top-level consists of starting three threads, and then entering a loop. As long as there are existing threads, the top-level waits for events (described next), and then acts upon the incoming messages. For each thread which received a response, a check is made to see if the OID of the response is greater than or equal to the exclusive upper-bound of the thread. If so, the portion of the table corresponding to the thread has been completely retrieved, so the thread is destroyed.
トップレベルは3個の糸を始動して、次に、輪を入れるのから成ります。 既存の糸がある限り、トップレベルは、出来事(次に、説明される)を待っていて、次に、入力メッセージに作用します。 応答を受けた各糸に関しては、応答のOIDが糸の排他的な上限以上であるかどうか考えるのをチェックをします。 そうだとすれば、糸に対応するテーブルの一部を完全に検索してあるので、糸は破壊されます。
Otherwise, the variable bindings in the response are stored. Following this, if a new thread should be created, then the portion of the table corresponding to the thread is split accordingly. Regardless, another powerful get-next operator is issued on behalf of the thread.
さもなければ、応答における変項束縛は格納されます。 これに続いて、新しい糸が作成されるなら、糸に対応するテーブルの一部がそれに従って、分けられます。 不注意に、糸を代表して別の強力な気付いているオペレータを発行します。
The initial starting positions (column, column.127, and column.192), were selected to form optimal partitions for tables which are indexed by IP addresses. The algorithm could easily be modified to choose other partitions; however, it must be stressed that the current choices work for any tabular object.
(コラム、コラム.127、およびコラム.192)がIPアドレスによって索引をつけられるテーブルのための最適のパーティションを形成するのが選択されたという初期の開始位置。 他のパーティションを選ぶように容易にアルゴリズムを変更できました。 しかしながら、現在の選択はどんな表物にも効き目があると強調しなければなりません。
pipelined_algorithm (column)
OID column;
{
pipelined_アルゴリズム(コラム)OIDコラム。 {
Rose, McCloghrie & Davin [Page 5] RFC 1187 Bulk Table Retrieval with the SNMP October 1990
ローズ、McCloghrie、およびデーヴィン[5ページ]RFC1187は1990年10月にSNMPとのテーブル検索を膨らませます。
timeout ::= some initial value;
タイムアウト:、:= 或るものは値に頭文字をつけます。
start new thread for [column, column.127);
start new thread for [column.127, column.192);
start new thread for [column.192, column+1);
[コラム、コラム.127)のために新しい糸を始動してください; [コラム.127、コラム.192)のために新しい糸を始動してください; [コラム.192、コラム+1)のために新しい糸を始動してください。
while (threads exist) {
wait for events;
foreach (thread that has an incoming message,
examined in order from the thread queue) {
OID a;
ゆったり過ごす(糸は存在している)、foreach(糸の待ち行列によって整然とした状態で調べられた入力メッセージを持っている糸)に出来事を待ってください、OID a。
if (message's OID >= thread's upper-bound) {
destroy thread;
continue;
}
(メッセージのOID>=スレッドの上限)です。糸を破壊してください; 続いてください;。
store variable-bindings from message;
メッセージから変項束縛を格納してください。
if (number of simultaneous threads does NOT
exceed a maximum number
&& NOT backoff
&& (a ::= oid_median (message's OID,
thread's
upper-bound))) {
start new thread for [a, thread's upper-bound);
thread's upper-bound ::= a;
place thread at end of thread queue;
backoff ::= TRUE;
}
do another get-next for thread;
}
}
}
(同時の糸の数が最大数を超えていない、どんなbackoff、も[a、スレッドの上限)a; 糸の待ち行列の終わりの場所糸; backoff: : (スレッドの上限: : ==TRUE)のための(a: : =oid_メディアン(メッセージのOID、スレッドの上限))スタートの新しい糸がそうしない、別のものが気付く、糸のために。
4.5. Wait for Events
4.5. 出来事を待ってください。
Waiting for events consists of waiting a small amount of time or until at least one message is received.
出来事を待つのは少量の時間か少なくとも1つのメッセージが受信されるまで待つのから成ります。
Any messages encountered are then collated with the appropriate thread. In addition, the largest round-trip time for request/responses is measured, and the maximum number of active threads is calculated.
そして、遭遇するどんなメッセージも適切な糸に照合されます。 さらに、要求/応答のための最も大きい往復の時間は測定されます、そして、アクティブな糸の最大数は計算されます。
Next, the timeout is adjusted: if no responses were received, then the timeout is doubled; otherwise, a timeout-adjustment is calculated
次に、タイムアウトは調整されます: 応答を全く受けなかったなら、タイムアウトを倍にします。 さもなければ、タイムアウト調整は計算されます。
Rose, McCloghrie & Davin [Page 6] RFC 1187 Bulk Table Retrieval with the SNMP October 1990
ローズ、McCloghrie、およびデーヴィン[6ページ]RFC1187は1990年10月にSNMPとのテーブル検索を膨らませます。
as 1.5 times the largest observed round-trip time. If the timeout- adjustment is greater than the current timeout, the current timeout is set to the timeout-adjustment. Otherwise, the current timeout is averaged with the timeout-adjustment.
1.5回として、最も大きいのは往復の時間を観測しました。 タイムアウト調整が現在のタイムアウトより大きいなら、現在のタイムアウトはタイムアウト調整に設定されます。 さもなければ、現在のタイムアウトはタイムアウト調整で平均されています。
Finally, if at least one thread did not receive a response, then the thread is identified which has waited the longest. If the elapsed time (with noise factor) since the last request (or retransmission) is greater than the current timeout value, another retransmission is attempted.
最終的に、少なくとも1個の糸が応答を受けなかったなら、糸は特定されます(最も長い間、待っています)。 最後の要求(または、「再-トランスミッション」)が現在のタイムアウト値より大きい時から経過時間であるなら(雑音指数がある)、別の「再-トランスミッション」は試みられます。
wait for events ()
{
backoff ::= TRUE, maxrtt ::= 0;
find the thread which has been waiting the longest
for a response;
timedelta = timeout
- time since request was sent for thread;
wait up to timedelta seconds or until some messages arrive;
出来事()を待ってください、backoff: : =TRUE、maxrtt: : =0; 糸のために要求を送ったので、最も長い間timedeltaがタイムアウトと等しいという応答を待っている糸に時間を見つけてください; timedelta秒かいくつかのメッセージが到着するまで、待ってください。
if (least one message arrived) {
discard any messages which aren't responses;
foreach (response which corresponds to a thread) {
if (the response is a duplicate)
drop it and continue;
(最少の1つのメッセージが到着しました)、foreachに応答でないあらゆるメッセージ(糸に対応する応答)を捨ててください、(応答は写しです) それを落としてください、そして、続いてください。
if (this response is for a message that was
not retransmitted) {
if (the round-trip time is larger than maxrtt)
set maxrtt to the new round-trip time;
if (round-trip time / number of active threads
< minimum previous round-trip time / number
of active threads) {
set new minimum round-trip time per number of
active threads
set new maximum number of threads
}
backoff ::= FALSE;
}
}
}
if (backoff)
double timeout;
elsif (maxrtt > 0) {
timeadjust ::= maxrtt * 3 / 2;
if (timeadjust > timeout)
timeout ::= timeadjust; backoff ::= TRUE;
else
(この応答は再送されなかったメッセージのためのものです) 新しい往復の時間までのmaxrtt; 設定されるなら(往復の時間はmaxrttより大きいです)、(アクティブの前の<最小の往復の時間/数が糸を通すアクティブな糸の往復の時間/数)であるならアクティブな糸の数あたりの新しい最小の往復の時間、backoffに設定新しい最大数の糸を設定してください: : =FALSE (backoff)であるなら、タイムアウトを倍にしてください。 elsif(maxrtt>0)、timeadjust:、:= maxrtt*3 / 2。 以下のこと、(timeadjust>タイムアウト)タイムアウトであるなら:= timeadjust。 backoff:、:= 本当。 ほか
Rose, McCloghrie & Davin [Page 7] RFC 1187 Bulk Table Retrieval with the SNMP October 1990
ローズ、McCloghrie、およびデーヴィン[7ページ]RFC1187は1990年10月にSNMPとのテーブル検索を膨らませます。
timeout ::= (timeout + timeadjust) / 2;
}
if (timeout exceeds some threshold)
set timeout to that threshold;
elsif (timeout is smaller than some threshold)
set timeout to that threshold;
タイムアウト:、:= (タイムアウト+timeadjust) / 2; その敷居への(タイムアウトは何らかの敷居を超えています)セットタイムアウトであるなら。 elsif(タイムアウトは何らかの敷居より小さい)はその敷居にタイムアウトを設定しました。
if (at least one thread didn't receive a response) {
find the thread which has been waiting the longest
for a response,
and determine the elapsed time since a message
was sent;
if (the elapsed time with noise is greater than timeout) {
if (the number of retransmissions for this thread
exceeds a threshold)
abort the algorithm;
retransmit the request;
backoff ::= TRUE;
}
}
}
(少なくとも1個の糸は応答を受けませんでした)、最も長い間応答を待っている糸を見つけてください、そして、メッセージを送ったので、経過時間を決定してください;、(雑音を伴う経過時間はタイムアウトよりすばらしいです) アルゴリズム; (この糸のための「再-トランスミッション」の数は敷居を超えています)アボートであるなら、要求を再送してください; backoff: : =TRUE
4.6. Finding the Median between two OIDs
4.6. 2OIDsの間のMedianを見つけます。
The object identifier space is neither uniform nor continuous. As such, it is not always possible to choose an object identifier which is lexicographically-between two arbitrary object identifiers. In view of this, the pipelined algorithm makes a best-effort attempt.
物の識別子スペースは、一定でなくて、また連続していません。 そういうものとして、2つの間の辞書編集の任意の物の識別子である物の識別子を選ぶのはいつも可能であるというわけではありません。 これから見て、pipelinedアルゴリズムは最大限の努力の試みをします。
Starting from the beginning, each sub-identifier of the two OIDs is scanned until a difference is encountered. At this point there are several possible conditions:
始めから始めて、違いが遭遇するまで、2OIDsに関するそれぞれのサブ識別子はスキャンされます。 ここに、いくつかの可能な状態があります:
(1) The upper OID has run out of sub-identifiers. In this
case, either the two OIDs are are identical or the lower
OID is greater than the upper OID (an interface error),
so no OID is returned.
(1) 上側のOIDはサブ識別子を使い果たしました。 同じであるか、より低いことはOIDです。この場合2OIDsがそう、上側であるよりすばらしいOIDは(インタフェース誤り)であり、したがって、OIDを全く返しません。
(2) The lower OID has run out of sub-identifiers. In this
case, the first subsequent non-zero sub-identifier from
the upper OID is located. If no such sub-identifier is
found, then no OID exists between the lower and upper
OIDs, and no OID is returned. Otherwise, a copy of the
upper OID is made, but truncated at this non-zero
sub-identifier, which is subsequently halved, and the
resulting OID is returned.
(2) 下側のOIDはサブ識別子を使い果たしました。 この場合、上側のOIDからのサブ識別子の最初のその後の非ゼロは見つけられています。 何かそのようなサブ識別子が見つけられないなら、どんなOIDも下側の、そして、上側のOIDsの間に存在していません、そして、OIDを全く返しません。 さもなければ、この非ゼロサブ識別子では、上側のOIDのコピーに作りますが、先端を切らせます、そして、結果として起こるOIDを返します。(識別子は次に、半分にされます)。
(3) Otherwise, a copy of the lower OID is made, but truncated
(3) さもなければ、下側のOIDのコピーは、作られていますが、先端を切られます。
Rose, McCloghrie & Davin [Page 8] RFC 1187 Bulk Table Retrieval with the SNMP October 1990
ローズ、McCloghrie、およびデーヴィン[8ページ]RFC1187は1990年10月にSNMPとのテーブル検索を膨らませます。
at the point of difference. This last sub-identifier is
then set to the arithmetic mean of the difference. In
the case where the difference is only 1 (so the last
sub-identifier remains the same) then a new sub-
identifier is added, taking care to be larger than a
possible sub-identifier present in the lower OID.
Regardless, the resulting OID is returned.
違いのポイントで。 そして、この最後のサブ識別子は違いの算術平均に設定されます。 違いが1であるにすぎない(したがって、最後のサブ識別子は同じままで残っている)場合では、次に、新しいサブ識別子は加えられます、下側のOIDの現在の可能なサブ識別子より大きくなるように注意して。 不注意に、結果として起こるOIDを返します。
oid_median (lower, upper)
OID lower,
upper;
{
for (i ::= 1; i < upper:nelem; i++) {
if (i > lower:nelem) {
while (upper:elems[i] == 0)
if (++i > upper:nelem)
return NULL;
median ::= copy of upper;
median:nelem ::= i;
median:elems[i] ::= upper:elems[i] / 2;
oid_メディアン(下側の、そして、上側の)OIDは上側で下ろします。 (i: : =1; i<覚醒剤: nelem; i++)、(i>は下ろされます: nelem)である、(+ + i>覚醒剤: nelem)リターンNULL; メディアン: : より上にの=コピー; メディアン: nelem: : =iであるメディアン: elems[i]: : =覚醒剤: (elems[i] / 2)ならゆったり過ごします(覚醒剤: elems[i]=0)。
return median;
}
メディアンを返してください。 }
if (lower:elems[i] == upper:elems[i])
continue;
(下ろしてください: elems[i]=覚醒剤: elems[i])は続きます。
median ::= copy of lower;
median:nelem ::= i;
median:elems[i] ::= (lower:elems[i]+upper:elems[i])/2;
if (median:elems[i] == lower:elems[i]) {
median:nelem ::= (i + 1);
if (lower:nelem < i)
median:elems[median:nelem] ::= 127;
elsif ((x ::= lower:elems[i + 1]) >= 16383)
median:elems[median:nelem] ::= x + 16383;
elsif (x >= 4095)
median:elems[median:nelem] ::= x + 4095;
elsif (x >= 1023)
median:elems[median:nelem] ::= x + 1023;
elsif (x >= 255)
median:elems[median:nelem] ::= x + 255;
else median:elems[median:nelem] ::=
(x / 2) + 128;
}
メディアン:、:= より低くコピーする、。 メディアン: nelem:、:= i。 メディアン: elems[i]:、:= (: elems[i]+覚醒剤: elems[i])を下ろしてください。/2; (メディアン: =が下ろすelems[i]: elems[i]){ median:nelem ::= (i + 1); if (lower:nelem < i) median:elems[median:nelem] ::= 127; elsif ((x ::= lower:elems[i + 1]) >= 16383) median:elems[median:nelem] ::= x + 16383; elsif (x >= 4095) median:elems[median:nelem] ::= x + 4095; elsif (x >= 1023) median:elems[median:nelem] ::= x + 1023; elsif (x >= 255) median:elems[median:nelem] ::= x + 255; else median:elems[median:nelem] ::= (x / 2) + 128; }
return median;
}
メディアンを返してください。 }
Rose, McCloghrie & Davin [Page 9] RFC 1187 Bulk Table Retrieval with the SNMP October 1990
ローズ、McCloghrie、およびデーヴィン[9ページ]RFC1187は1990年10月にSNMPとのテーブル検索を膨らませます。
return NULL;
}
NULLを返してください。 }
4.7. Experience with the Pipelined Algorithm
4.7. Pipelinedアルゴリズムの経験
This pipelined algorithm has been implemented and some experimentation has been performed. It would be premature to provide extensive performance figures at this time, as the pipelined algorithm is still being tuned, and is implemented only in a prototype setting. However, on tables of size O(2500), performance of 121 entries/second has been observed. In contrast, the serial algorithm has performance of roughly 56 entries/second for the same table.
このpipelinedアルゴリズムは実行されました、そして、何らかの実験が実行されました。 このとき大量の性能の数字を明らかにするのは時期尚早でしょう、pipelinedアルゴリズムがまだ調整されていて、原型設定だけで実行されるとき。 しかしながら、サイズO(2500)のテーブルでは、121エントリー/秒の性能は観測されました。 対照的に、連続のアルゴリズムには、同じテーブルのためのおよそ56エントリー/秒の性能があります。
4.8. Dynamic Range of Timeout Values
4.8. タイムアウト値のダイナミックレンジ
It should be noted that the pipelined algorithm takes a simplistic approach with the timeout value: it does not maintain a history of the value and act accordingly.
pipelinedアルゴリズムがタイムアウト値に関する安易なアプローチを取ることに注意されるべきです: それはそれに従って、値と行為の歴史を維持しません。
For example, if the timeout reaches the maximum timeout limit, and then latches for some period of time, this indicates a resource (either the network or the agent) is saturated. Unfortunately, a solution is difficult: an elegant approach would be to combine two threads (but it is quite possible that no two consecutive threads exist when this determination is made). Another approach might be to delay the transmission for threads which are ready to issue a new get-next operation.
例えば、タイムアウトが最大のタイムアウト限界に達して、次に、いつかの期間の間、掛け金をおろすなら、これは、リソース(ネットワークかエージェントのどちらか)が飽和しているのを示します。 残念ながら、解決策は難しいです: 上品なアプローチは2個の糸を結合するだろう(この決断をするとき、2個の連続した糸が存在しないのは、かなり可能です)ことです。 別のアプローチは新しい気付いている操作を発行する準備ができている糸のためのトランスミッションを遅らせることであるかもしれません。
Similarly, if the timeout drops to the minimum value and subsequently latches, more threads should be started.
同様に、タイムアウトが最小値に落ちて、次に掛け金をおろすなら、より多くの糸が始動されるべきです。
4.9. Incorrect Agent Implementations
4.9. 不正確なエージェント実現
An interesting result is that many agents do not properly implement the powerful get-next operator. In particular, when a get-next request contains an operand with an arbitrarily-generated suffix, some agent implementations will handle this improperly, and ultimately return a result which is lexicographically less than the operand!
おもしろい結果は多くのエージェントが適切に強力な気付いているオペレータを実行しないということです。 気付いている要求が任意に発生している接尾語があるオペランドを含んでいると、いくつかのエージェント実現が、特に、不適切にこれを扱って、結局、オペランドよりそれほど辞書編集である結果を返すでしょう!
A typical cause of this is when the instance-identifier for a columnar object is formed by a MAC or IP address, so each octet of the address forms a sub-identifier of the instance-identifier. In such circumstances, the incorrect agent implementations compare against only the least significant octet of the sub-identifiers in the operand, instead of the full value of the sub-identifiers.
この典型的な原因が円柱状の物のための例識別子がMACかIPアドレスによって形成される時であるので、アドレスの各八重奏は例識別子に関するサブ識別子を形成します。 そのような事情では、不正確なエージェント実現はサブ識別子のオペランドで最も重要でない八重奏だけに対して比較されます、サブ識別子の全額の代わりに。
Rose, McCloghrie & Davin [Page 10] RFC 1187 Bulk Table Retrieval with the SNMP October 1990
ローズ、McCloghrie、およびデーヴィン[10ページ]RFC1187は1990年10月にSNMPとのテーブル検索を膨らませます。
Upon encountering such an interaction, the pipelined algorithm implementation declares the thread dead (noting a possible gap in the table), and continues.
そのような相互作用に遭遇すると、pipelinedアルゴリズム実装は、糸が死んでいると(テーブルの可能なギャップに注意します)宣言して、続きます。
5. The Parallel Algorithm
5. 平行なアルゴリズム
One interesting optimization is to view the problem in two steps: in the first step, one column of the table is traversed to determine the full range of instances identifiers meaningful in the table. (Indeed, although as described above, the pipelined algorithm retrieves a single column, the prototype implementation can retrieve multiple columns). In the second step, additional columns can be retrieved using the SNMP get operation, since the instance identifiers are already known. Further, the manager can dynamically determine how many variables can be placed in a single SNMP get operation in order to minimize the number of requests. Of course, since the agent's execution of the get operation is often less expensive than execution of the powerful get-next operation, when multiple columns are request, this two-step process requires less execution time on the agent.
1つのおもしろい最適化は以下の2ステップで問題を見ることです: 第一歩では、テーブルに関する1つのコラムが、テーブルで重要な例の識別子の最大限の範囲を決定するために横断されます。 (本当に、pipelinedアルゴリズムは上で説明されるようにシングル・コラムを検索しますが、原型実現は複数のコラムを検索できます。) 第2ステップでは、追加コラムはSNMPが操作を得る検索された使用であることができます、例の識別子が既に知られているので。 さらに、マネージャは、SNMPが要求の数を最小にするために操作を得るシングルにいくつの変数を置くことができるかをダイナミックに決心できます。 得てください。もちろん、エージェントの処刑、操作は強力な気付いている操作の実行よりしばしば高価であるというわけではありません。(複数のコラムが要求である、その時、この二段構えの体制はエージェントの上の、より少ない実行時間を必要とします)。
A second algorithm can be developed, the "parallel algorithm". At present, each thread is mapped onto a single SNMP operation. A powerful insight is to suggest mapping several threads onto a single SNMP operation: the manager must dynamically determine how many variables can be placed in a single powerful get-next operation. This has the advantage of reducing traffic, at the expense of requiring the agent to utilize more resources for each request.
2番目のアルゴリズムを開発できる、「平行なアルゴリズム。」 現在のところ、各糸はただ一つのSNMP操作に写像されます。 強力な洞察はただ一つのSNMP操作に数個の糸を写像するのを示すことです: マネージャは、ただ一つの強力な気付いている操作にいくつの変数を置くことができるかをダイナミックに決心しなければなりません。 これには、交通を抑える利点があります、エージェントが各要求のための、より多くのリソースを利用するのが必要であることを犠牲にして。
Earlier it was noted that the serial retrieval of objects could be viewed as a degenerate case of the pipelined algorithm, in which the number of active threads was one. Similarly, the pipelined algorithm is a special case of the parallel algorithm, in which the number of threads per SNMP operation is one.
より早く、アクティブな糸の数が1であったpipelinedアルゴリズムの堕落したケースとして物の連続の検索を見なすことができることに注意されました。 同様に、pipelinedアルゴリズムは平行なアルゴリズムの特別なケースです。(それでSNMP操作あたりの糸の数は1です)。
5.1. Experience with the Parallel Algorithm
5.1. 平行なアルゴリズムの経験
The parallel algorithm has been implemented and some experimentation has been performed. It would be premature to provide extensive performance figures at this time, as the algorithm is still being tuned, and is implemented only in a prototype setting. However, on tables of size O(2500), performance of 320 entries/second has been observed, a performance improvement of 571% over the serial algorithm.
平行なアルゴリズムは実装されました、そして、何らかの実験が実行されました。 このとき大量の性能の数字を明らかにするのは時期尚早でしょう、アルゴリズムがまだ調整されていて、プロトタイプ設定だけで実装されるとき。 しかしながら、サイズO(2500)のテーブルでは、320エントリー/秒の性能は観測されました、連続のアルゴリズムの上の571%の性能改良。
6. Acknowledgements
6. 承認
A lot of the ideas on pipelining are motivated by Van Jacobson's work
パイプライン処理に関する多くの考えがヴァン・ジェーコブソンの仕事で動機づけられています。
Rose, McCloghrie & Davin [Page 11] RFC 1187 Bulk Table Retrieval with the SNMP October 1990
ローズ、McCloghrie、およびデーヴィン[11ページ]RFC1187は1990年10月にSNMPとのテーブル検索を膨らませます。
on adaptive timers in TCP. The parallelization modifications were originally suggested by Jeffrey D. Case.
TCPの適応型のタイマに関して。 並列化変更は元々、ジェフリーD.Caseによって勧められました。
Finally, the comments of the following individual is acknowledged:
最終的に、以下の個人のコメントは承諾されます:
Frank Kastenholz, Racal-Interlan
フランクKastenholz、Racal-Interlan
7. References
7. 参照
[1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, Simple
Network Management Protocol (SNMP), RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[1] ケースとJ.とヒョードルとM.とSchoffstall、M.とJ.デーヴィン、簡単なネットワーク管理プロトコル(SNMP)、RFC1157、SNMPは研究します、国際言語運用機構、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Marshall T. Rose PSI, Inc. PSI California Office P.O. Box 391776 Mountain View, CA 94039
マウンテンビュー、マーシャルT.バラψInc.ψカリフォルニアオフィスP.O. Box391776カリフォルニア 94039
Phone: (415) 961-3380 EMail: mrose@PSI.COM
以下に電話をしてください。 (415) 961-3380 メールしてください: mrose@PSI.COM
Keith McCloghrie Hughes LAN Systems 1225 Charleston Road Mountain View, CA 94043
マウンテンビュー、キースMcCloghrieヒューズLANシステム1225チャールストンRoadカリフォルニア 94043
Phone: (415) 966-7934 EMail: KZM@HLS.COM
以下に電話をしてください。 (415) 966-7934 メールしてください: KZM@HLS.COM
James R. Davin MIT Laboratory for Computer Science, NE43-507 545 Technology Square Cambridge, MA 02139
ジェームスR.デーヴィンMITコンピュータサイエンス研究所、NE43-507 545の技術の正方形のケンブリッジ、MA 02139
Phone: (617) 253-6020 EMail: jrd@ptt.lcs.mit.edu
以下に電話をしてください。 (617) 253-6020 メールしてください: jrd@ptt.lcs.mit.edu
Rose, McCloghrie & Davin [Page 12]
ローズ、McCloghrie、およびデーヴィン[12ページ]
一覧
スポンサーリンク
