RFC998 日本語訳
0998 NETBLT: A bulk data transfer protocol. D.D. Clark, M.L. Lambert,L. Zhang. March 1987. (Format: TXT=57147 bytes) (Obsoletes RFC0969) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group David D. Clark
Request for Comments: 998 Mark L. Lambert
Obsoletes: RFC 969 Lixia Zhang
MIT
March 1987
コメントを求めるワーキンググループデヴィッドD.クラークの要求をネットワークでつないでください: 998 マークL.ランバートは以下を時代遅れにします。 RFC969LixiaチャンMIT March1987
NETBLT: A Bulk Data Transfer Protocol
NETBLT: バルク・データ転送プロトコル
1. Status
1. 状態
This document is a description of, and a specification for, the NETBLT protocol. It is a revision of the specification published in NIC RFC-969. The protocol has been revised after extensive research into NETBLT's performance over long-delay, high-bandwidth satellite channels. Most of the changes in the protocol specification have to do with the computation and use of data timers in a multiple buffering data transfer model.
このドキュメントが記述である、仕様、NETBLTは議定書を作ります。 それはNIC RFC-969で発表された仕様の改正です。 プロトコルは長時間の遅延、高帯域衛星チャンネルの上のNETBLTの性能の大規模な調査の後に改訂されました。 プロトコル仕様に基づく変化の大部分はデータ転送モデルをバッファリングする倍数におけるデータタイマの計算と使用と関係があります。
This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised.
このドキュメントは、議論とコメントのために発行されて、規格を構成しません。 提案は変化するかもしれません、そして、プロトコルのある部分はまだ指定されていません。 したがって、このドキュメントの実装は教えられません。
2. Introduction
2. 序論
NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP.
NETBLT(NETwork BLock Transfer)は平らなプロトコルがコンピュータの間の多量のデータの迅速な移転のために意図した輸送です。 それが信頼できる転送を供給して、流れは、制御して、さまざまなネットワークの上に最大のスループットを提供するように設計されています。 NETBLTは現在インターネットプロトコル(IP)の上で稼働しますが、それは機能においてIPと同様のどんなデータグラムプロトコルの上でも作動できるべきです。
NETBLT's motivation is to achieve higher throughput than other protocols might offer. The protocol achieves this goal by trying to minimize the effect of several network-related problems: network congestion, delays over satellite links, and packet loss.
NETBLTの動機は他のプロトコルが提供するかもしれないより高いスループットを達成することです。 プロトコルはいくつかのネットワーク関連の問題の影響を最小にしようとすることによって、この目標を実現します: 混雑、衛星中継の上の遅れ、およびパケット損失をネットワークでつないでください。
Its transmission rate-control algorithms deal well with network congestion; its multiple-buffering capability allows high throughput over long-delay satellite channels, and its various timeout/retransmit algorithms minimize the effect of packet loss during a transfer. Most importantly, NETBLT's features give it good performance over long-delay channels without impairing performance over high-speed LANs.
通信速度コントロールアルゴリズムはネットワークの混雑によく対処します。 複数バッファリングしている能力は高生産性を許容します。長時間の遅延衛星チャンネル、および/が再送するその様々なタイムアウトの上では、アルゴリズムは転送の間、パケット損失の影響を最小にします。 最も重要に、性能を損なわないで、NETBLTの特徴は高速LANの上で長時間の遅延の上の望ましい市場成果チャンネルをそれに与えます。
Clark, Lambert, & Zhang [Page 1] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[1ページ]RFC998March
The protocol works by opening a connection between two "clients" (the "sender" and the "receiver"), transferring the data in a series of large data aggregates called "buffers", and then closing the connection. Because the amount of data to be transferred can be very large, the client is not required to provide at once all the data to the protocol module. Instead, the data is provided by the client in buffers. The NETBLT layer transfers each buffer as a sequence of packets; since each buffer is composed of a large number of packets, the per-buffer interaction between NETBLT and its client is far more efficient than a per-packet interaction would be.
プロトコルは2「クライアント」(「送付者」と「受信機」)の間の接続を開くことによって、働いています、「バッファ」と呼ばれて、次に、接続を終えながら一連の大きいデータ集合体でデータを移して。 移されるべきデータ量が非常に大きい場合があるので、クライアントはすぐに、すべてのデータをプロトコルモジュールに提供する必要はありません。 代わりに、データはクライアントによってバッファに提供されます。 NETBLT層はパケットの系列として各バッファを移します。 各バッファが多くのパケットで構成されるので、NETBLTとそのクライアントとの1バッファあたりの相互作用は1パケットあたり1回の相互作用であるだろうよりはるかに効率的です。
In its simplest form, a NETBLT transfer works as follows: the sending client loads a buffer of data and calls down to the NETBLT layer to transfer it. The NETBLT layer breaks the buffer up into packets and sends these packets across the network in Internet datagrams. The receiving NETBLT layer loads these packets into a matching buffer provided by the receiving client. When the last packet in the buffer has arrived, the receiving NETBLT checks to see that all packets in that buffer have been correctly received. If some packets are missing, the receiving NETBLT requests that they be resent. When the buffer has been completely transmitted, the receiving client is notified by its NETBLT layer. The receiving client disposes of the buffer and provides a new buffer to receive more data. The receiving NETBLT notifies the sender that the new buffer is ready, and the sender prepares and sends the next buffer in the same manner. This continues until all the data has been sent; at that time the sender notifies the receiver that the transmission has been completed. The connection is then closed.
最も簡単なフォームでは、NETBLT転送は以下の通り働いています: 送付クライアントは、データに関するバッファをロードして、それを移すためにNETBLT層まで電話をします。 NETBLT層は、パケットにバッファを壊れさせて、インターネットデータグラムのネットワークの向こう側にこれらのパケットを送ります。受信NETBLT層は受信クライアントによって提供された合っているバッファにこれらのパケットを積み込みます。 バッファにおける最後のパケットが到着したとき、受信NETBLTは、そのバッファのすべてのパケットが正しく受け取られたのを確実にするためにチェックします。 いくつかのパケットがなくなるなら、受信NETBLTは、それらが再送されるよう要求します。 バッファが完全に伝えられたとき、受信クライアントはNETBLT層のそばで通知されます。 受信クライアントは、バッファを処分して、より多くのデータを受け取るために新しいバッファを提供します。 受信NETBLTは、新しいバッファが準備ができていて、送付者が同じ方法による次のバッファを準備して、送るように送付者に通知します。 これはすべてのデータを送るまで続きます。 その時、送付者は、トランスミッションが終了したことを受信機に通知します。 そして、接続は閉店します。
As described above, the NETBLT protocol is "lock-step". Action halts after a buffer is transmitted, and begins again after confirmation is received from the receiver of data. NETBLT provides for multiple buffering, a transfer model in which the sending NETBLT can transmit new buffers while earlier buffers are waiting for confirmation from the receiving NETBLT. Multiple buffering makes packet flow essentially continuous and markedly improves performance.
上で説明されるように、NETBLTプロトコルは「堅苦しいです」。 バッファが伝えられて、データの受信機から確認を受け取った後にやり直した後に動作は停止します。 NETBLTは複数のバッファリング(以前のバッファが受信NETBLTから確認を待っている間に発信しているNETBLTが新しいバッファを伝えることができる転送モデル)に備えます。 複数のバッファリングが、パケット流動を本質的には連続するようにして、性能を著しく向上させます。
The remainder of this document describes NETBLT in detail. The next sections describe the philosophy behind a number of protocol features: packetization, flow control, transfer reliability, and connection management. The final sections describe NETBLT's packet formats.
このドキュメントの残りは詳細にNETBLTについて説明します。 次のセクションは多くのプロトコル機能の後ろで哲学について説明します: packetization、フロー制御は信頼性、および接続管理を移します。 最後のセクションはNETBLTのパケット・フォーマットについて説明します。
3. Buffers and Packets
3. バッファとパケット
NETBLT is designed to permit transfer of a very large amounts of data between two clients. During connection setup the sending NETBLT can inform the receiving NETBLT of the transfer size; the maximum transfer length is 2**32 bytes. This limit should permit any practical application. The transfer size parameter is for the use of the receiving client; the receiving NETBLT makes no use of it. A
NETBLTは、2人のクライアントの間の非常に多量のデータの転送を可能にするように設計されています。 接続設定の間、発信しているNETBLTは転送サイズについて受信NETBLTに知らせることができます。 最大の転送の長さは32バイト2**です。 この限界はどんな実用化も可能にするべきです。 転送サイズ・パラメータは受信クライアントの使用のためのものです。 受信NETBLTはそれの無駄をします。 A
Clark, Lambert, & Zhang [Page 2] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[2ページ]RFC998March
NETBLT receiver accepts data until told by the sender that the transfer is complete.
転送が完全であると送付者によって言われるまで、NETBLT受信機はデータを受け入れます。
The data to be sent must be broken up into buffers by the client. Each buffer must be the same size, save for the last buffer. During connection setup, the sending and receiving NETBLTs negotiate the buffer size, based on limits provided by the clients. Buffer sizes are in bytes only; the client is responsible for placing data in buffers on byte boundaries.
クライアントは送られるデータをバッファに終えなければなりません。 各バッファは最後のバッファ以外の同じサイズであるに違いありません。 接続設定の間、送受信NETBLTsはクライアントによって提供された限界に基づいてバッファサイズを交渉します。 バッファサイズがバイトだけであります。 クライアントはバッファのデータをバイト境界に置くのに責任があります。
NETBLT has been designed and should be implemented to work with buffers of any size. The only fundamental limitation on buffer size should be the amount of memory available to the client. Buffers should be as large as possible since this minimizes the number of buffer transmissions and therefore improves performance.
NETBLTは設計されていて、どんなサイズに関するバッファでも仕事に実装されるべきです。 バッファサイズにおける唯一の基本的な制限がクライアントにとって、有効なメモリー容量であるべきです。 これがバッファトランスミッションの数を最小にして、したがって、性能を向上させるので、バッファはできるだけ大きいはずです。
NETBLT is designed to require a minimum amount of memory, allowing the client to allocate as much memory as possible for buffer storage. In particular, NETBLT does not keep buffer copies for retransmission purposes. Instead, data to be retransmitted is recopied directly from the client buffer. This means that the client cannot release buffer storage piece by piece as the buffer is sent, but this has not been a problem in preliminary NETBLT implementations.
NETBLTは最小の量のメモリを必要とするように設計されています、クライアントができるだけ緩衝記憶装置において多くのメモリを割り当てるのを許容して。 特に、NETBLTは「再-トランスミッション」目的のためにバッファ写しを取っておきません。 代わりに、再送されるべきデータは直接クライアントバッファから再コピーされます。 バッファを送るとき、クライアントが断片で緩衝記憶装置断片をリリースできないことを意味しますが、これは予備のNETBLT実装では問題ではありません。
Buffers are broken down by the NETBLT layer into sequences of DATA packets. As with the buffer size, the DATA packet size is negotiated between the sending and receiving NETBLTs during connection setup. Unlike buffer size, DATA packet size is visible only to the NETBLT layer.
バッファはNETBLT層のそばでDATAパケットの系列へ砕けています。 バッファサイズのように、DATAパケットサイズは接続設定の間、送受信NETBLTsの間で交渉されます。 バッファサイズと異なって、DATAパケットサイズはNETBLT層だけに目に見えます。
All DATA packets save the last packet in a buffer must be the same size. Packets should be as large as possible, since NETBLT's performance is directly related to packet size. At the same time, the packets should not be so large as to cause internetwork fragmentation, since this normally causes performance degradation.
パケットがバッファで最後のパケットを保存するすべてのDATAが同じサイズであるに違いありません。 NETBLTの性能が直接パケットサイズに関連するので、パケットはできるだけ大きいはずです。 同時に、パケットは原因インターネットワーク断片化に関してそれほど大きいはずがありません、これが通常性能退行を引き起こすので。
All buffers save the last buffer must be the same size; the last buffer can be any size required to complete the transfer. Since the receiving NETBLT does not know the transfer size in advance, it needs some way of identifying the last packet in each buffer. For this reason, the last packet of every buffer is not a DATA packet but rather an LDATA packet. DATA and LDATA packets are identical save for the packet type.
すべてのバッファが同じくらいがサイズであったに違いないなら最後のバッファを保存します。 最後のバッファは転送を終了するのに必要であるサイズであるかもしれません。 受信NETBLTがあらかじめ転送サイズを知らないので、それは各バッファにおける最後のパケットを特定する何らかの方法を必要とします。 この理由で、DATAパケットではなく、あらゆるバッファの最後のパケットはむしろLDATAパケットです。 パケットタイプを除いて、DATAとLDATAパケットは同じです。
4. Flow Control
4. フロー制御
NETBLT uses two strategies for flow control, one internal and one at the client level.
NETBLTはクライアントレベルにフロー制御、1における、内部の2つの戦略と1つを使用します。
The sending and receiving NETBLTs transmit data in buffers; client flow control is therefore at a buffer level. Before a buffer can be
送受信NETBLTsはバッファのデータを送ります。 クライアントフロー制御がしたがって、バッファレベルにあります。 バッファがそうであるのになることができる前に
Clark, Lambert, & Zhang [Page 3] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[3ページ]RFC998March
transmitted, NETBLT confirms that both clients have set up matching buffers, that one is ready to send data, and that the other is ready to receive data. Either client can therefore control the flow of data by not providing a new buffer. Clients cannot stop a buffer transfer once it is in progress.
伝えられます、NETBLTは両方のクライアントが合っているバッファをセットアップして、1つがデータを送る準備ができていて、もう片方をデータを受け取る準備ができていると確認します。 したがって、どちらのクライアントも、新しいバッファを提供しないことによって、データの流れを制御できます。 いったん進行していると、クライアントはバッファ転送を止めることができません。
Since buffers can be quite large, there has to be another method for flow control that is used during a buffer transfer. The NETBLT layer provides this form of flow control.
バッファがかなり大きい場合があるので、バッファ転送の間に使用されるフロー制御のための別のメソッドがなければなりません。 NETBLT層はこのフォームのフロー制御を提供します。
There are several flow control problems that could arise while a buffer is being transmitted. If the sending NETBLT is transferring data faster than the receiving NETBLT can process it, the receiver's ability to buffer unprocessed packets could be overflowed, causing packet loss. Similarly, a slow gateway or intermediate network could cause packets to collect and overflow network packet buffer space. Packets will then be lost within the network. This problem is particularly acute for NETBLT because NETBLT buffers will generally be quite large, and therefore composed of many packets.
バッファが伝えられている間に起こることができたいくつかのフロー制御問題があります。 発信しているNETBLTが受信NETBLTがそれを処理できるより速くデータを移しているなら、未加工のパケットをバッファリングする受信機の性能ははみ出すかもしれません、パケット損失を引き起こして。 同様に、遅いゲートウェイか中間ネットワークが集めるパケットとオーバーフローネットワークパケットバッファ領域を引き起こす場合がありました。 そして、パケットはネットワークの中で失われるでしょう。 NETBLTバッファが一般にかなり大きくて、したがって、多くのパケットを落ち着かせるので、NETBLTには、この問題は特に鋭いです。
A traditional solution to packet flow control is a window system, in which the sending end is permitted to send only a certain number of packets at a time. Unfortunately, flow control using windows tends to result in low throughput. Windows must be kept small in order to avoid overflowing hosts and gateways, and cannot easily be updated, since an end-to-end exchange is required for each window change.
パケットフロー制御への伝統的な解決はウィンドウシステムです。(そこでは、送信側が一度にある数のパケットだけを送ることが許可されています)。 残念ながら、窓を使用するフロー制御は、少ないスループットをもたらす傾向があります。 Windowsをホストとゲートウェイからはみ出すのを避けるために小さく保たなければならなくて、容易にアップデートできません、終わりから終わりへの交換がそれぞれのウィンドウ変化に必要であるので。
To permit high throughput over a variety of networks and gateways, NETBLT uses a novel flow control method: rate control. The transmission rate is negotiated by the sending and receiving NETBLTs during connection setup and after each buffer transmission. The sender uses timers, rather than messages from the receiver, to maintain the negotiated rate.
さまざまなネットワークとゲートウェイの上で高生産性を可能にするために、NETBLTは目新しいフロー制御メソッドを使用します: コントロールを評定してください。 通信速度は接続設定とそれぞれのバッファトランスミッションの後に送受信NETBLTsによって交渉されます。 送付者は、交渉されたレートを維持するのに受信機からのメッセージよりむしろタイマを使用します。
In its simplest form, rate control specifies a minimum time period per packet transmission. This can cause performance problems for several reasons. First, the transmission time for a single packet is very small, frequently smaller than the granularity of the timing mechanism. Also, the overhead required to maintain timing mechanisms on a per packet basis is relatively high and lowers performance.
最も簡単なフォームでは、速度制御は1パケット伝送あたり1回の最小の期間を指定します。 これはいくつかの理由で性能問題を引き起こす場合があります。 まず最初に、単一のパケットのためのトランスミッション時間は、非常にわずかであって、タイミングメカニズムの粒状より頻繁にわずかです。 また、パケット基礎あたりのaでタイミングメカニズムを維持するのに必要であるオーバーヘッドは、比較的高く、性能を下げます。
The solution is to control the transmission rate of groups of packets, rather than single packets. The sender transmits a burst of packets over a negotiated time interval, then sends another burst. In this way, the overhead decreases by a factor of the burst size, and the per-burst transmission time is long enough that timing mechanisms will work properly. NETBLT's rate control therefore has two parts, a burst size and a burst rate, with (burst size)/(burst rate) equal to the average transmission time per packet.
ソリューションは単一のパケットよりむしろパケットのグループの通信速度を制御することです。 送付者は、交渉された時間間隔の上にパケットの炸裂を伝えて、次に、別の炸裂を送ります。 このように、オーバーヘッドは放出量の要素で下がります、そして、1バースト伝送あたりの時間はタイミングメカニズムが適切に動作するほど長いです。 したがって、NETBLTの速度制御には、(放出量)/(レートを押し破きます)に従った2つの部品、放出量、および炸裂率が1パケットあたりの平均したトランスミッション時間までの同輩にあります。
Clark, Lambert, & Zhang [Page 4] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[4ページ]RFC998March
The burst size and burst rate should be based not only on the packet transmission and processing speed which each end can handle, but also on the capacities of any intermediate gateways or networks. Following are some intuitive values for packet size, buffer size, burst size, and burst rate.
放出量と炸裂率は各端が扱うことができるパケット伝送と処理速度に基づいているだけではなく、どんな中間ゲートウェイやネットワークの能力にも基づくべきです。 以下に、パケットサイズ、バッファサイズ、放出量、および炸裂率のためのいくつかの直感的な値があります。
Packet sizes can be as small as 128 bytes. Performance with packets this small is almost always bad, because of the high per-packet processing overhead. Even the default Internet Protocol packet size of 576 bytes is barely big enough for adequate performance. Most networks do not support packet sizes much larger than one or two thousand bytes, and packets of this size can also get fragmented when traveling over intermediate networks, lowering performance.
パケットサイズは128バイトと同じくらい小さいことができます。 パケットがこれほど小さいパフォーマンスは1パケットあたりの高い処理オーバヘッドのためにほとんどいつも悪いです。 適切な性能には、576バイトのデフォルトインターネットプロトコルパケットサイズさえ十分ほとんど大きくはありません。 ほとんどのネットワークは1バイトか2,000バイトよりはるかに大きいパケットサイズをサポートしません、そして、また、中間ネットワークの上を旅行するとき、このサイズのパケットは断片化できます、性能を下げて。
The size of a NETBLT buffer is limited only by the amount of memory available to a client. Theoretically, buffers of 100 Kbytes or more are possible. This would mean the transmission of 50 to 100 packets per buffer.
NETBLTバッファのサイズはクライアントにとって、有効なメモリー容量だけによって制限されます。 理論的に、100キロバイト以上のバッファは可能です。 これは1バッファあたり50〜100のパケットのトランスミッションを意味するでしょう。
The burst size and burst rate are obviously very machine dependent. There is a certain amount of transmission overhead in the sending and receiving machines associated with maintaining timers and scheduling processes. This overhead can be minimized by sending packets in large bursts. There are also limitations imposed on the burst size by the number of available packet buffers in the operating system kernel. On most modern operating systems, a burst size of between five and ten packets should reduce the overhead to an acceptable level. A preliminary NETBLT implementation for the IBM PC/AT sends packets in bursts of five. It could send more, but is limited by the available memory.
放出量と炸裂率は明らかにマシンに非常に依存しています。 ある量のトランスミッションオーバーヘッドがタイマを維持して、プロセスの計画をすると関連している送受信マシンにあります。 大きい炸裂でパケットを送ることによって、このオーバーヘッドを最小にすることができます。 オペレーティングシステムカーネルにおける、利用可能なパケットバッファの数によって放出量に課された制限もあります。 ほとんどの近代的なオペレーティングシステムでは、5〜10のパケットの放出量は合格水準にオーバーヘッドを引き下げるべきです。 IBM PC/ATのための予備のNETBLT実装は5の炸裂でパケットを送ります。 それは、さらに発信できましたが、利用可能なメモリによって制限されます。
The burst rate is in part determined by the granularity of the sender's timing mechanism, and in part by the processing speed of the receiver and any intermediate gateways. It is also directly related to the burst size. Burst rates from 20 to 45 milliseconds per 5- packet burst have been tried on the IBM PC/AT and Symbolics 3600 NETBLT implementations with good results within a single local-area network. This value clearly depends on the network bandwidth and packet buffering available.
炸裂率は送付者のタイミングメカニズムの粒状、および一部受信機とどんな中間ゲートウェイの処理速度によっても一部測定されます。 また、それは直接放出量に関連します。 5パケット炸裂あたり20〜45ミリセカンドの炸裂率はただ一つのローカル・エリア・ネットワークの中でIBM PC/ATとSymbolics3600NETBLT実装で良い結果で試験済みでした。 この値は明確に利用可能なネットワーク回線容量とパケットバッファリングであることに依存します。
All NETBLT flow control parameters (packet size, buffer size, burst size, and burst rate) are negotiated during connection setup. The negotiation process is the same for all parameters. The client initiating the connection (the active end) proposes and sends a set of values for each parameter in its connection request. The other client (the passive end) compares these values with the highest- performance values it can support. The passive end can then modify any of the parameters, but only by making them more restrictive. The modified parameters are then sent back to the active end in its response message.
すべてのNETBLTフロー制御パラメタ(パケットサイズ(バッファサイズ)は、サイズを押し破いて、レートを押し破いた)が接続設定の間、交渉されます。 すべてのパラメタに、交渉プロセスは同じです。 接続(アクティブな終わり)を開始するクライアントは、接続要求における各パラメタのために1セットの値を提案して、送ります。 もう片方のクライアント(受け身の終わり)はサポートすることができる中で最も高い性能値とこれらの値を比べます。 次に、パラメタのどれかを変更しますが、受け身の終わりは、単にそれらをより制限するようにすることによって、そうすることができます。 そして、応答メッセージへのアクティブな終わりは変更されたパラメタに送り返されます。
Clark, Lambert, & Zhang [Page 5] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[5ページ]RFC998March
The burst size and burst rate can also be re-negotiated after each buffer transmission to adjust the transfer rate according to the performance observed from transferring the previous buffer. The receiving end sends burst size and burst rate values in its OK messages (described later). The sender compares these values with the values it can support. Again, it may then modify any of the parameters, but only by making them more restrictive. The modified parameters are then communicated to the receiver in a NULL-ACK packet, described later.
また、それぞれのバッファトランスミッションの後に前のバッファを移すのから観測された性能に応じて転送レートを調整するために放出量と炸裂率を再交渉できます。 犠牲者はOKメッセージ(後で説明される)の放出量と炸裂レート値を送ります。 送付者はそれがサポートすることができる値とこれらの値を比べます。 一方、次に、パラメタのどれかを変更しますが、それは、単にそれらをより制限するようにすることによって、そうするかもしれません。 そして、変更されたパラメタは後で説明されたNULL-ACKパケットの受信機に伝えられます。
Obviously each of the parameters depend on many factors -- gateway and host processing speeds, available memory, timer granularity -- some of which cannot be checked by either client. Each client must therefore try to make as best a guess as it can, tuning for performance on subsequent transfers.
明らかに、それぞれのパラメタはどちらのクライアントがもそれの或るものをチェックできない多くの要素(ゲートウェイとホスト・プロセッシングは疾走します、利用可能なメモリ、タイマ粒状)に依存します。 各クライアントはしたがって、その後の転送に関する性能のために調整して、することができるように最善として推測をしようとしなければなりません。
5. The NETBLT Transfer Model
5. NETBLT転送モデル
Each NETBLT transfer has three stages, connection setup, data transfer, and connection close. The stages are described in detail below, along with methods for insuring that each stage completes reliably.
それぞれのNETBLT転送には、3つのステージ、接続設定、データ転送、および接続が近くにあります。 ステージは各ステージが確かに完了する保障のためのメソッドと共に以下で詳細に説明されます。
5.1. Connection Setup
5.1. 接続設定
A NETBLT connection is set up by an exchange of two packets between the active NETBLT and the passive NETBLT. Note that either NETBLT can send or receive data; the words "active" and "passive" are only used to differentiate the end making the connection request from the end responding to the connection request. The active end sends an OPEN packet; the passive end acknowledges the OPEN packet in one of two ways. It can either send a REFUSED packet, indicating that the connection cannot be completed for some reason, or it can complete the connection setup by sending a RESPONSE packet. At this point the transfer can begin.
NETBLT接続はアクティブなNETBLTと受け身のNETBLTの間の2つのパケットの交換でセットアップされます。 NETBLTがデータを送るか、または受け取ることができることに注意してください。 単語「アクティブ」、そして、「受動態」は、終わりを差別化するのに接続要求に応じながら終わりから接続要求をしながら、使用されるだけです。 アクティブな終わりはオープンパケットを送ります。 受け身の終わりは2つの方法の1つでオープンパケットを承認します。 それはREFUSEDパケットを送ることができます、接続がある理由で終了できないか、またはRESPONSEパケットを送ることによって接続設定を終了できるのを示して。 ここに、転送は始まることができます。
As discussed in the previous section, the OPEN and RESPONSE packets are used to negotiate flow control parameters. Other parameters used in the data transfer are also negotiated. These parameters are (1) the maximum number of buffers that can be sending at any one time, and (2) whether or not DATA packet data will be checksummed. NETBLT automatically checksums all non-DATA/LDATA packets. If the negotiated checksum flag is set to TRUE (1), both the header and the data of a DATA/LDATA packet are checksummed; if set to FALSE (0), only the header is checksummed. The checksum value is the bitwise negation of the ones-complement sum of the 16-bit words being checksummed.
前項で議論するように、オープンとRESPONSEパケットはフロー制御パラメタを交渉するのに使用されます。 また、データ転送で使用される他のパラメタは交渉されます。 これらのパラメタは、DATAパケットデータが(2)であるか否かに関係なく、(1) いかなる時も発信できるバッファの最大数、そして、(2)です。checksummedにされる。 NETBLT、自動的にチェックサム、すべての非DATA/LDATAパケット。 交渉されたチェックサム旗がTRUE(1)に設定されるなら、ヘッダーとDATA/LDATAパケットに関するデータの両方がchecksummedされます。 FALSE(0)に設定されるなら、ヘッダーだけがchecksummedされます。 チェックサム値がそうである、bitwiseする、checksummedされる16ビットの単語のもの補数の合計の否定。
Finally, each end transmits its death-timeout value in seconds in either the OPEN or the RESPONSE packet. The death-timeout value will be used to determine the frequency with which to send KEEPALIVE
最終的に、各端は秒にオープンかRESPONSEパケットのどちらかで死亡タイムアウト値を送ります。 死亡タイムアウト値は、KEEPALIVEを送る頻度を測定するのに使用されるでしょう。
Clark, Lambert, & Zhang [Page 6] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[6ページ]RFC998March
packets during idle periods of an opened connection (death timers and KEEPALIVE packets are described in the following section).
開かれた接続(死亡タイマとKEEPALIVEパケットは以下のセクションで説明される)の活動していない期間のパケット。
The active end specifies a passive client through a client-specific "well-known" 16 bit port number on which the passive end listens. The active end identifies itself through a 32 bit Internet address and a unique 16 bit port number.
アクティブな終わりは受け身の終わりが聴く16ビットのクライアント特有の「よく知られる」ポートナンバーを通して受け身のクライアントを指定します。 アクティブな終わりは32ビットのインターネット・アドレスと16ビットのユニークなポートナンバーを通してそれ自体を特定します。
In order to allow the active and passive ends to communicate miscellaneous useful information, an unstructured, variable-length field is provided in OPEN and RESPONSE packets for any client- specific information that may be required. In addition, a "reason for refusal" field is provided in REFUSED packets.
アクティブで受け身の終わりが種々雑多な役に立つ情報を伝えるのを許容して、必要であるクライアント特殊情報のために不統一で、可変長の野原をオープンとRESPONSEパケットに提供します。 さらに、「拒否の理由」野原をREFUSEDパケットに提供します。
Recovery for lost OPEN and RESPONSE packets is provided by the use of timers. The active end sets a timer when it sends an OPEN packet. When the timer expires, another OPEN packet is sent, until some predetermined maximum number of OPEN packets have been sent. The timer is cleared upon receipt of a RESPONSE packet.
タイマの使用で無くなっているオープンとRESPONSEパケットのための回復を供給します。 それがオープンパケットを送るとき、アクティブな終わりはタイマを設定します。 タイマが期限が切れるとき、何らかの予定された最大数のオープンパケットを送るまで別のオープンパケットを送ります。 タイマはRESPONSEパケットを受け取り次第きれいにされます。
To prevent duplication of OPEN and RESPONSE packets, the OPEN packet contains a 32 bit connection unique ID that must be returned in the RESPONSE packet. This prevents the initiator from confusing the response to the current request with the response to an earlier connection request (there can only be one connection between any two ports). Any OPEN or RESPONSE packet with a destination port matching that of an open connection has its unique ID checked. If the unique ID of the packet matches the unique ID of the connection, then the packet type is checked. If it is a RESPONSE packet, it is treated as a duplicate and ignored. If it is an OPEN packet, the passive NETBLT sends another RESPONSE (assuming that a previous RESPONSE packet was sent and lost, causing the initiating NETBLT to retransmit its OPEN packet). A non-matching unique ID must be treated as an attempt to open a second connection between the same port pair and is rejected by sending an ABORT message.
オープンとRESPONSEパケットの複製を防ぐために、オープンパケットはRESPONSEパケットで返さなければならない32ビットの接続固有のIDを含んでいます。 これによって、創始者は現在の要求への応答を以前の接続要求への応答に間違えることができません(どんな2つのポートの間にはも、1つの接続しかあることができません)。 どんなオープンや仕向港がオープンな接続のものに合っているRESPONSEパケットでも、固有のIDをチェックします。 パケットの固有のIDが接続の固有のIDに合っているなら、パケットタイプはチェックされます。 RESPONSEパケットであるなら、それは、写しとして扱われて、無視されます。 それがオープンパケットであるなら、受け身のNETBLTは別のRESPONSE(開始しているNETBLTがオープンパケットを再送することを引き起こして、前のRESPONSEパケットが送られて、失われたと仮定する)を送ります。 非合っている固有のIDは、同じように2番目の接続を開く試みとして扱われたポート組でなければならなく、ABORTメッセージを送ることによって、拒絶されます。
5.2. Data Transfer
5.2. データ転送
The simplest model of data transfer proceeds as follows. The sending client sets up a buffer full of data. The receiving NETBLT sends a GO message inside a CONTROL packet to the sender, signifying that it too has set up a buffer and is ready to receive data. Once the GO message is received, the sender transmits the buffer as a series of DATA packets followed by an LDATA packet. When the last packet in the buffer has been received, the receiver sends a RESEND message inside a CONTROL packet containing a list of packets that were not received. The sender resends these packets. This process continues until there are no missing packets. At that time the receiver sends an OK message inside a CONTROL packet, sets up another buffer to receive data, and sends another GO message. The sender, having received the OK message, sets up another buffer, waits for the GO
データ転送の最も簡単なモデルは以下の通り続きます。 送付クライアントはデータでいっぱいのバッファをセットアップします。 受信NETBLTは送付者へのCONTROLパケットにGOメッセージを送ります、それがもバッファをセットアップして、データを受け取る準備ができているのを意味して。 GOメッセージがいったん受信されるようになると、一連のDATAパケットがLDATAパケットで続いたので、送付者はバッファを伝えます。 バッファにおける最後のパケットを受け取ったとき、受信機は受け取られなかったパケットのリストを含むCONTROLパケットにRESENDメッセージを送ります。 送付者はこれらのパケットを再送します。 どんななくなったパケットもないまで、このプロセスは持続します。 その時、受信機は、OKメッセージをCONTROLパケットに送って、データを受け取るために別のバッファをセットアップして、別のGOメッセージを送ります。 送付者(OKメッセージを受け取った別のバッファへのセット)はGOを待ちます。
Clark, Lambert, & Zhang [Page 7] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[7ページ]RFC998March
message, and repeats the process.
通信してください。そうすれば、反復はプロセスを通信させます。
The above data transfer model is effectively a lock-step protocol, and causes time to be wasted while the sending NETBLT waits for permission to send a new buffer. A more efficient transfer model uses multiple buffering to increase performance. Multiple buffering is a technique in which the sender and receiver allocate and transmit buffers in a manner that allows error recovery or successful transmission confirmation of previous buffers to be concurrent with transmission of the current buffer.
上のデータ転送モデルは、事実上堅苦しいプロトコルであり、発信しているNETBLTが新しいバッファを送る許可を待っている間に浪費されるべき時間を引き起こします。 より有能な転送モデルは、性能を増強するのに複数のバッファリングを使用します。 複数のバッファリングが送付者と受信機が前のバッファのエラー回復かうまくいっているトランスミッション確認が現在のバッファの伝達で同時発生であることを許容する方法によるバッファを割り当てて、伝えるテクニックです。
During the connection setup phase, one of the negotiated parameters is the number of concurrent buffers permitted during the transfer. If there is more than one buffer available, transfer of the next buffer may start right after the current buffer finishes. This is illustrated in the following example:
接続設定段階の間、交渉されたパラメタの1つは転送の間に受入れられた同時発生のバッファの数です。 利用可能な1つ以上のバッファがあれば、現在のバッファが終わったまさしく後に次のバッファの転送は始まるかもしれません。 これは以下の例で例証されます:
Assume two buffers A and B in a multiple-buffer transfer, with A preceding B. When A has been transferred and the sending NETBLT is waiting for either an OK or a RESEND message for it, the sending NETBLT can start sending B immediately, keeping data flowing at a stable rate. If the receiver of data sends an OK for A, all is well; if it receives a RESEND, the missing packets specified in the RESEND message are retransmitted.
2つのバッファがAであると仮定して、AがB.When Aに先行している複数のバッファ転送におけるBを移しました、そして、発信しているNETBLTはそれへのOKかRESENDメッセージのどちらかを待っています、NETBLTがすぐにBを送り始めることができる送付、データを安定した速度で流れさせ続けて。 データの受信機がAのためにOKを送るなら、すべてが順調です。 RESENDを受けるなら、RESENDメッセージで指定されたなくなったパケットは再送されます。
In the multiple-buffer transfer model, all packets to be sent are re-ordered by buffer number (lowest number first), with the transfer rate specified by the burst size and burst rate. Since buffer numbers increase monotonically, packets from an earlier buffer will always precede packets from a later buffer.
複数のバッファ転送モデルで、バッファ数で送られるすべてのパケットを再注文する、(最も下位の数、1番目) 転送レートで、放出量と炸裂率に従って、指定されています。 バッファ数が単調に増加するので、以前のバッファからのパケットは後のバッファからパケットにいつも先行するでしょう。
Having several buffers transmitting concurrently is actually not that much more complicated than transmitting a single buffer at a time. The key is to visualize each buffer as a finite state machine; several buffers are merely a group of finite state machines, each in one of several states. The transfer process consists of moving buffers through various states until the entire transmission has completed.
一度に、いくつかのバッファを同時に伝えさせるのは、実際に伝わるよりはるかにそんなに複雑なただ一つのバッファではありません。 キーは有限状態機械として各バッファを想像することになっています。 いくつかのバッファが単にそれぞれいくつかの州の1つの有限状態機械のグループです。 転送プロセスはトランスミッションが完成した全体までバッファを様々な州を通って動かすのから成ります。
There are several obvious flaws in the data transfer model as described above. First, what if the GO, OK, or RESEND messages are lost? The sender cannot act on a packet it has not received, so the protocol will hang. Second, if an LDATA packet is lost, how does the receiver know when the buffer has been transmitted? Solutions for each of these problems are presented below.
データ転送モデルにはいくつかの明白な欠点が上で説明されるようにあります。 まず最初にGO、OKかRESENDメッセージが無くなると、どうなるでしょうか? 送付者がそれが受けていないパケットに影響できないので、プロトコルは掛かるでしょう。 2番目に、LDATAパケットが無くなるなら、受信機は、バッファがいつ伝えられたかをどのように知っていますか? それぞれのこれらの問題のためのソリューションは以下に提示されます。
5.2.1. Recovering from Lost Control Messages
5.2.1. 無くなっているコントロールメッセージから、回復します。
NETBLT solves the problem of lost OK, GO, and RESEND messages in two ways. First, it makes use of a control timer. The receiver can send one or more control messages (OK, GO, or RESEND) within a single
NETBLTは2つの方法で無くなっているOK、GO、およびRESENDメッセージの問題を解決します。 まず最初に、それは制御タイマを利用します。 受信機はシングルの中で1つ以上のコントロールメッセージ(OK、GO、またはRESEND)を送ることができます。
Clark, Lambert, & Zhang [Page 8] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[8ページ]RFC998March
CONTROL packet. Whenever the receiver sends a control packet, it sets a control timer. This timer is either "reset" (set again) or "cleared" (deactivated), under the following conditions:
CONTROLパケット。 受信機がコントロールパケットを送るときはいつも、それは制御タイマを設定します。 このタイマは、以下の条件の下で「リセットされる」か(再び、設定します)、または「クリアされる」(非活性化されます):
When the control timer expires, the receiving NETBLT resends the control packet and resets the timer. The receiving NETBLT continues to resend control packets in response to control timer's expiration until either the control timer is cleared or the receiving NETBLT's death timer (described later) expires (at which time it shuts down the connection).
制御タイマが期限が切れると、受信NETBLTはコントロールパケットを再送して、タイマをリセットします。 受信NETBLTは、制御タイマの制御タイマがきれいにされるまでの満了かNETBLTの死亡タイマ(後で説明される)が吐き出す(それがどの時に接続を止めるかとき)受信に対応してコントロールパケットを再送し続けています。
Each control message includes a sequence number which starts at one and increases by one for each control message sent. The sending NETBLT checks the sequence number of every incoming control message against all other sequence numbers it has received. It stores the highest sequence number below which all other received sequence numbers are consecutive (in following paragraphs this is called the high-acknowledged-sequence-number) and returns this number in every packet flowing back to the receiver. The receiver is permitted to clear its control timer when it receives a packet from the sender with a high-acknowledged-sequence-number greater than or equal to the highest sequence number in the control packet just sent.
それぞれのコントロールメッセージはそれぞれのコントロールメッセージのための1時の始めと1の増加が送った一連番号を含んでいます。 発信しているNETBLTはそれが受けた他のすべての一連番号に対してあらゆる入って来るコントロールメッセージの一連番号をチェックします。 それは、他のすべての容認された一連番号が連続している(次のパラグラフで、これは高い承認された一連番号と呼ばれます)最も高い一連番号を保存して、受信機に注いで戻りながら、あらゆるパケットでこの数を返します。受信機による送付者から高い承認された一連番号でパケットをより受けるとき、制御タイマをきれいにすることが許可されて、コントロールパケットで最も高い一連番号がただ発信したということです。
Ideally, a NETBLT implementation should be able to cope with out-of- sequence control messages, perhaps collecting them for later processing, or even processing them immediately. If an incoming control message "fills" a "hole" in a group of message sequence numbers, the implementation could even be clever enough to detect this and adjust its outgoing sequence value accordingly.
理想的に、NETBLT実装は外で対処できるべきです。-系列では、メッセージを制御してください、後で処理するために恐らくそれらを集めるか、またはすぐにそれらを処理さえして。 入って来るコントロールメッセージがメッセージ通番のグループの「穴」を「いっぱいにしている」なら、実装はこれを検出して、それに従って、外向的な系列値を調整できるくらい賢明でさえあるかもしれません。
The sending NETBLT, upon receiving a CONTROL packet, should act on the packet as quickly as possible. It either sets up a new buffer (upon receipt of an OK message for a previous buffer), marks data for resending (upon receipt of a RESEND message), or prepares a buffer for sending (upon receipt of a GO message). If the sending NETBLT is not in a position to send data, it should send a NULL-ACK packet, which contains its high-acknowledged-sequence-number (this permits the receiving NETBLT to acknowledge any outstanding control messages), and wait until it can send more data. In all of these cases, the system overhead for a response to the incoming control message should be small and relatively constant.
CONTROLパケットを受けるとき、発信しているNETBLTはできるだけはやくパケットに影響するはずです。 それは、新しいバッファ(前のバッファへのOKメッセージを受け取り次第)をセットアップするか、再送(RESENDメッセージを受け取り次第)のためにデータをマークするか、または発信する(GOメッセージを受け取り次第)ためにバッファを準備します。 発信しているNETBLTがデータを送る立場にないなら、それは、より多くのデータを送ることができるまでNULL-ACKパケットを送って、待つべきです。(パケットは高い承認された一連番号(これは、受信NETBLTがどんな傑出しているコントロールメッセージも承認することを許可する)を含みます)。 全部で、入って来るコントロールメッセージへの応答のためのシステムオーバーヘッドは、これらの場合では、わずかであって、比較的一定であるべきです。
The small amount of message-processing overhead allows accurate control timers to be set for all types of control messages with a single, simple algorithm -- the network round-trip transit time, plus a variance factor. This is more efficient than schemes used by other protocols, where timer value calculation has been a problem because the processing time for a particular packet can vary greatly depending on the packet type.
少量のメッセージ処理オーバーヘッドが、正確な制御タイマが単一の、そして、簡単なアルゴリズムがあるすべてのタイプに関するコントロールメッセージに設定されるのを許容します--ネットワークの往復のトランジット時間、および変化の要素。 これは他のプロトコルによって使用される体系より効率的です。そこでは、パケットタイプに大いに頼っていて、特定のパケットのための処理時間が異なることができるので、タイマ値の計算が問題です。
Control timer value estimation is extremely important in a high-
コントロールタイマ値の見積りは高値で非常に重要です。
Clark, Lambert, & Zhang [Page 9] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[9ページ]RFC998March
performance protocol like NETBLT. A long control timer causes the receiving NETBLT to wait for long periods of time before retransmitting unacknowledged messages. A short control timer value causes the sending NETBLT to receive many duplicate control messages (which it can reject, but which takes time).
NETBLTのような性能プロトコル。 長い制御タイマで、不承認のメッセージを再送する前に、受信NETBLTは長期間の間、待ちます。 短いコントロールタイマ価値で、発信しているNETBLTは多くの写しコントロールメッセージを受け取ります(拒絶できますが、時間がかかります)。
In addition to the use of control timers, NETBLT reduces lost control messages by using a single long-lived control packet; the packet is treated like a FIFO queue, with new control messages added on at the end and acknowledged control messages removed from the front. The implementation places control messages in the control packet and transmits the entire control packet, consisting of any unacknowledged control messages plus new messages just added. The entire control packet is also transmitted whenever the control timer expires. Since control packet transmissions are fairly frequent, unacknowledged messages may be transmitted several times before they are finally acknowledged. This redundant transmission of control messages provides automatic recovery for most control message losses over a noisy channel.
制御タイマの使用に加えて、NETBLTは単一の長命のコントロールパケットを使用することによって、無くなっているコントロールメッセージを減らします。 パケットは先入れ先出し待ち行列のように扱われます、新しいコントロールメッセージが終わりに加えられて、承認されたコントロールメッセージが前部から取り除かれている状態で。 実装は、コントロールメッセージをコントロールパケットに置いて、全体のコントロールパケットを伝えます、ただ加えられたどんな不承認のコントロールメッセージと新しいメッセージからも成って。 また、制御タイマが期限が切れるときはいつも、全体のコントロールパケットは伝えられます。 コントロールパケット伝送がかなり頻繁であるので、それらが最終的に承認される前に、不承認のメッセージは何度か送られるかもしれません。 コントロールメッセージのこの余分な伝達は騒がしいチャンネルの上にほとんどのコントロールメッセージの損失に自動復旧を供給します。
This scheme places some burdens on the receiver of the control messages. It must be able to quickly reject duplicate control messages, since a given message may be retransmitted several times before its acknowledgement is received and it is removed from the control packet. Typically this is fairly easy to do; the sender of data merely throws away any control messages with sequence numbers lower than its high-acknowledged-sequence-number.
この体系はコントロールメッセージの受信機にいくつかの負担をかけます。 それはすぐに写しコントロールメッセージを拒絶できなければなりません、承認が受け取られている前に何度か与えられたメッセージを再送するかもしれなくて、コントロールパケットからそれを取り除くので。 通常、これはかなりしやすいです。 一連番号が高い承認された一連番号より低い状態でデータの送付者は単にどんなコントロールメッセージも無駄にします。
Another problem with this scheme is that the control packet may become larger than the maximum allowable packet size if too many control messages are placed into it. This has not been a problem in the current NETBLT implementations: a typical control packet size is 1000 bytes; RESEND control messages average about 20 bytes in length, GO messages are 8 bytes long, and OK messages are 16 bytes long. This allows 50-80 control messages to be placed in the control packet, more than enough for reasonable transfers. Other implementations can provide for multiple control packets if a single control packet may not be sufficient.
この体系に関する別の問題はあまりに多くのコントロールメッセージがそれに置かれるならコントロールパケットが最大の許容できるパケットサイズより大きくなるかもしれないということです。 これは現在のNETBLT実装で問題ではありません: 典型的なコントロールパケットサイズは1000バイトです。 RESENDコントロールメッセージは長さおよそ20バイトを平均します、そして、GOメッセージは8バイト長です、そして、OKメッセージは16バイト長です。 これは50-80 コントロールパケットに置かれて、合理的な転送において十二分になるコントロールメッセージを許容します。 単一管理パケットが十分でないかもしれないなら、他の実装は複合管理パケットに備えることができます。
The control timer value must be carefully estimated. It can have as its initial value an arbitrary number. Subsequent control packets should have their timer values based on the network round-trip transit time (i.e. the time between sending the control packet and receiving the acknowledgment of all messages in the control packet) plus a variance factor. The timer value should be continually updated, based on a smoothed average of collected round-trip transit times.
慎重にコントロールタイマ価値を見積もらなければなりません。 それは初期の値として特殊活字の数字を持つことができます。 その後のコントロールパケットは往復のトランジット時間(すなわち、コントロールパケットでコントロールパケットを送って、すべてのメッセージの承認を受けることの間の時間)と変化の要素をネットワークに基礎づけるはずでしたそれらのタイマが、評価する。 集まっている往復のトランジット時間の平坦な平均に基づいて絶えずタイマ値をアップデートするべきです。
Clark, Lambert, & Zhang [Page 10] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[10ページ]RFC998March
5.2.2. Recovering from Lost LDATA Packets
5.2.2. 無くなっているLDATAパケットから、回復します。
NETBLT solves the problem of LDATA packet loss by using a data timer for each buffer at the receiving end. The simplest data timer model has a data timer set when a buffer is ready to be received; if the data timer expires, the receiving NETBLT assumes a lost LDATA packet and sends a RESEND message requesting all missing DATA packets in the buffer. When all packets have been received, the timer is cleared.
NETBLTは、犠牲者の各バッファにデータタイマを使用することによって、LDATAパケット損失の問題を解決します。 バッファが受け取る準備ができているとき、最も簡単なデータタイマモデルはデータタイマを設定させます。 データタイマが期限が切れるなら、受信NETBLTはバッファで無くなっているLDATAパケットを仮定して、RESENDメッセージにすべてのなくなったDATAパケットを要求させます。 すべてのパケットを受け取ったとき、タイマをきれいにします。
Data timer values are not based on network round-trip transit time; instead they are based on the amount of time taken to transfer a buffer (as determined by the number of DATA packet bursts in the buffer times the burst rate) plus a variance factor <1>.
タイマ値が基づいていないデータは往復のトランジット時間をネットワークでつなぎます。 代わりに、それらはバッファ(DATAの数で決定するように、パケットはバッファ時代に炸裂率を押し破く)と変化の要素<を移すにはかかる時間に基づいています。1>。
Obviously an accurate estimation of the data timer value is very important. A short data timer value causes the receiving NETBLT to send unnecessary RESEND packets. This causes serious performance degradation since the sending NETBLT has to stop what it is doing and resend a number of DATA packets.
明らかに、データタイマ価値の正確な見積りは非常に重要です。 短いデータタイマ価値で、受信NETBLTは不要なRESENDパケットを送ります。 発信しているNETBLTがそれがしていることを止めて、多くのDATAパケットを再送しなければならないので、これは重大な性能退行を引き起こします。
Data timer setting and clearing turns out to be fairly complicated, particularly in a multiple-buffering transfer model. In understanding how and when data timers are set and cleared, it is helpful to visualize each buffer as a finite-state machine and take a look at the various states.
データタイマ設定と開拓地は、特に倍数をバッファリングする転送モデルで公正に複雑にされるために判明します。 データタイマがどのように、いつ設定されて、きれいにされるかを理解する際に、有限状態機械として各バッファを想像して、様々な州を見るのは役立っています。
The state sequence for a sending buffer is simple. When a GO message for the buffer is received, the buffer is created, filled with data, and placed in a SENDING state. When an OK for that buffer has been received, it goes into a SENT state and is disposed of.
送付バッファのためのステート・シーケンスは簡単です。 バッファへのGOメッセージが受信されているとき、バッファは、作成されて、データで満たされて、SENDING状態に置かれます。 そのバッファのためのOKを受け取ったとき、それにSENT状態に入って、処分します。
The state sequence for a receiving buffer is a little more complicated. Assume existence of a buffer A. When a control message for A is sent, the buffer moves into state ACK-WAIT (it is waiting for acknowledgement of the control message).
受信バッファのためのステート・シーケンスはもう少し複雑です。 Aへのコントロールメッセージが送られるバッファA.Whenの存在を仮定してください、州のACK-WAITへのバッファ移動(それはコントロールメッセージの承認を待っています)。
As soon as the control message has been acknowledged, buffer A moves from the ACK-WAIT state into the ACKED state (it is now waiting for DATA packets to arrive). At this point, A's data timer is set and the control message removed from the control packet. Estimation of the data timer value at this point is quite difficult. In a multiple-buffer transfer model, the receiving NETBLT can send several GO messages at once. A single DATA packet from the sending NETBLT could acknowledge all the GO messages, causing several buffers to start up data timers. Clearly each of the data timers must be set in a manner that takes into account each buffer's place in the order of transmission. Packets for a buffer A - 1 will always be transmitted before packets in A, so A's data timer must take into account the arrival of all of A - 1's DATA packets as well as arrival of its own DATA packets. This means that the timer values become increasingly less accurate for higher-numbered buffers. Because this data timer
コントロールメッセージが承認されるとすぐに、バッファAはACK-WAIT状態からACKED状態に移行します(それは、現在、DATAパケットが到着するのを待っています)。 ここに、Aのデータタイマは設定されました、そして、コントロールメッセージはコントロールパケットから取り除かれました。 ここのデータタイマ価値の見積りはかなり難しいです。 複数のバッファ転送モデルでは、受信NETBLTはすぐに、いくつかのGOメッセージを送ることができます。 発信しているNETBLTからの単一のDATAパケットはすべてのGOメッセージを承認するかもしれません、いくつかのバッファがデータタイマを立ち上げることを引き起こして。 明確に、トランスミッションの注文における各バッファの場所を考慮に入れる方法でそれぞれのデータタイマを設定しなければなりません。 バッファAのためのパケット--したがって、AのデータタイマはAのすべての到着を考慮に入れなければなりません--1はAでいつもパケットの前に伝えられて、それ自身のDATAパケットの到着と同様に1のDATAパケット。 これは、タイマ値がますますより高く番号付のバッファには、より正確でなくなることを意味します。 このデータタイマ
Clark, Lambert, & Zhang [Page 11] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[11ページ]RFC998March
value can be quite inaccurate, it is called a "loose" data timer. The loose data timer value is recalculated later (using the same algorithm, but with updated information), giving a "tight" timer, as described below.
値がかなり不正確である場合がある、それは「ゆるい」データタイマと呼ばれます。 ゆるいデータタイマ価値は後で再計算されます(同じアルゴリズムを使用しますがアップデートされた情報で)、「きつい」タイマを与えて、以下で説明されるように。
When the first DATA packet for A arrives, A moves from the ACKED state to the RECEIVING state and its data timer is set to a new "tight" value. The tight timer value is calculated in the same manner as the loose timer, but it is more accurate since we have moved forward in time and those buffers numbered lower than A have presumably been dealt with (or their packets would have arrived before A's), leaving fewer packets to arrive between the setting of the data timer and the arrival of the last DATA packet in A.
Aのための最初のDATAパケットが到着すると、AはACKED状態からRECEIVING状態まで移行します、そして、データタイマは新しい「きつい」値に設定されます。 きついタイマ値はゆるいタイマと同じ方法で計算されますが、私たちが時間内に、前方へ動いて、Aより低く付番されたそれらのバッファがおそらく対処されたので(それらのパケットはAのものの前に到着したでしょう)、それは、より正確です、より少ないパケットがデータタイマの設定と最後のDATAパケットのAへの到着の間で到着するのを残して。
The receiving NETBLT also sets the tight data timers of any buffers numbered lower than A that are also in the ACKED state. This is done as an optimization: we know that buffers are processed in order, lowest number first. If a buffer B numbered lower than A is in the ACKED state, its DATA packets should arrive before A's. Since A's have arrived first, B's must have gotten lost. Since B's loose data timer has not expired (it would then have sent a RESEND message and be in the ACK-WAIT state), we set the tight timer, allowing the missing packets to be detected earlier. An immediate RESEND is not sent because it is possible that A's packet was re-ordered before B's by the network, and that B's packets may arrive shortly.
また、受信NETBLTはACKED状態にもあるAより低く付番されたどんなバッファのきついデータタイマも設定します。 最適化としてこれをします: 私たちは、バッファが最初に注文、最も下位の数で処理されるのを知っています。 Aより低く付番されたバッファBがACKED状態にあるなら、DATAパケットはAのものの前に到着するはずです。 Aが先着したので、ビーズは失せたに違いありません。 ビーズのゆるいデータタイマが期限が切れていないので(それは、次に、RESENDメッセージを送って、ACK-WAIT状態にあるでしょう)、私たちはきついタイマを設定します、なくなったパケットが、より早く検出されるのを許容して。 Aのパケットがネットワークによる以前再命令されたビーズであり、ビーズパケットがまもなく到着するのが、可能であるので、即座のRESENDは送られません。
When all DATA packets for A have been received, it moves from the RECEIVING state to the RECEIVED state and is disposed of. Had any packets been missing, A's data timer would have expired and A would have moved into the ACK-WAIT state after sending a RESEND message. The state progression would then move as in the above example.
AのためのすべてのDATAパケットを受け取ったとき、それはRECEIVING状態からRECEIVED状態まで移行して、処分します。 どれかパケットがなくなったなら、Aのデータタイマは期限が切れたでしょうに、そして、RESENDメッセージを送った後に、AはACK-WAIT状態に移行したでしょう。 そして、州の進行は上記の例のように移行するでしょう。
The control and data timer system can be summarized as follows: normally, the receiving NETBLT is working under one of two types of timers, a control timer or a data timer. There is one data timer per buffer transmission and one control timer per control packet. The data timer is active while its buffer is in either the ACKED (loose data timer value is used) or the RECEIVING (tight data timer value is used) states; a control timer is active whenever the receiving NETBLT has any unacknowledged control messages in its control packet.
以下の通りコントロールとデータタイマシステムをまとめることができます: 通常、受信NETBLTは2つのタイプのタイマ、制御タイマまたはデータタイマの働くひとりです。 バッファトランスミッションあたり1個のデータタイマとコントロールパケットあたり1個の制御タイマがあります。 バッファがACKED(ゆるいデータタイマ価値は使用されている)かRECEIVING(きついデータタイマ価値は使用されている)州のどちらかにありますが、データタイマはアクティブです。 受信NETBLTがコントロールパケットにどんな不承認のコントロールメッセージも持っているときはいつも、制御タイマはアクティブです。
5.2.3. Death Timers and Keepalive Packets
5.2.3. 死亡タイマとKeepaliveパケット
The above system still leaves a few problems. If the sending NETBLT is not ready to send, it sends a single NULL-ACK packet to clear any outstanding control timers at the receiving end. After this the receiver will wait. The sending NETBLT could die and the receiver, with its control timer cleared, would hang. Also, the above system puts timers only on the receiving NETBLT. The sending NETBLT has no timers; if the receiving NETBLT dies, the sending NETBLT will hang while waiting for control messages to arrive.
上のシステムはまだいくつかの問題を残しています。発信しているNETBLTが発信する準備ができていないなら、それは、犠牲者のどんな傑出している制御タイマもきれいにするために単一のNULL-ACKパケットを送ります。 この後、受信機は待っています。 発信しているNETBLTは死ぬことができました、そして、制御タイマがきれいにされている状態で、受信機は掛かっているでしょう。 また、上のシステムは受信NETBLTにタイマを置くだけです。 発信しているNETBLTには、タイマが全くありません。 受信NETBLTが死ぬと、発信しているNETBLTは到着するコントロールメッセージを待っている間、掛かるでしょう。
Clark, Lambert, & Zhang [Page 12] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[12ページ]RFC998March
The solution to the above two problems is the use of a death timer and a keepalive packet for both the sending and receiving NETBLTs. As soon as the connection is opened, each end sets a death timer; this timer is reset every time a packet is received. When a NETBLT's death timer expires, it can assume the other end has died and can close the connection.
上の2つの問題への解決は死亡タイマとkeepaliveパケットの両方の送受信NETBLTsの使用です。 接続が開かれるとすぐに、各端は死亡タイマを設定します。 パケットが受け取られているときはいつも、このタイマはリセットされます。 NETBLTの死亡タイマが期限が切れると、それは、もう一方の端が死んで、接続を終えることができると仮定できます。
It is possible that the sending or receiving NETBLTs will have to wait for long periods while their respective clients get buffer space and load their buffers with data. Since a NETBLT waiting for buffer space is in a perfectly valid state, the protocol must have some method for preventing the other end's death timer from expiring. The solution is to use a KEEPALIVE packet, which is sent repeatedly at fixed intervals when a NETBLT cannot send other packets. Since the death timer is reset whenever a packet is received, it will never expire as long as the other end sends packets.
彼らのそれぞれのクライアントがバッファ領域を得て、彼らのバッファにデータを積みますが、送付かNETBLTsを受けるのが長期の間待っていなければならないのは、可能です。 バッファ領域を待つNETBLTが完全に有効な状態にあるので、プロトコルには、もう一方の端の死亡タイマが期限が切れるのを防ぐための何らかのメソッドがなければなりません。 ソリューションはKEEPALIVEパケットを使用することです。(それは、繰り返してNETBLTが他のパケットを送ることができない固定間隔で、送られます)。 パケットが受け取られているときはいつも、死亡タイマがリセットされるので、もう一方の端がパケットを送る限り、それは決して期限が切れないでしょう。
The frequency with which KEEPALIVE packets are transmitted is computed as follows: At connection startup, each NETBLT chooses a death-timer value and sends it to the other end in either the OPEN or the RESPONSE packet. The other end takes the death-timeout value and uses it to compute a frequency with which to send KEEPALIVE packets. The KEEPALIVE frequency should be high enough that several KEEPALIVE packets can be lost before the other end's death timer expires (e.g. death timer value divided by four).
KEEPALIVEパケットが伝えられる頻度は以下の通り計算されます: 接続始動では、各NETBLTは死亡タイマ値を選んで、オープンかRESPONSEパケットのどちらかへのもう一方の端にそれを送ります。 もう一方の端は、死亡タイムアウト値を取って、パケットをKEEPALIVEに送る頻度を計算するのにそれを使用します。 KEEPALIVE頻度はもう一方の端の死亡タイマが(例えば4によって分割された死亡タイマ価値)を吐き出す前にいくつかのKEEPALIVEパケットが失われる場合があるほど高いはずです。
The death timer value is relatively easy to estimate. Since it is continually reset, it need not be based on the transfer size. Instead, it should be based at least in part on the type of application using NETBLT. User applications should have smaller death timeout values to avoid forcing humans to wait long periods of time for a death timeout to occur. Machine applications can have longer timeout values.
死亡タイマ価値は比較的見積もりやすいです。 絶えずリセットされるので、それは転送サイズに基づく必要はありません。 代わりに、それは、アプリケーションのタイプにNETBLTを使用することで少なくとも一部基づくべきです。 ユーザアプリケーションには、タイムアウトが人間を長い期間の間、死亡タイムアウトが起こるのを待たせるのを避けるために評価するより小さい死があるべきです。 マシンアプリケーションは、より長いタイムアウト値を持つことができます。
5.3. Closing the Connection
5.3. 接続を終えます。
There are three ways to close a connection: a connection close, a "quit", or an "abort".
接続を終える3つの方法があります: 接続閉鎖、「辞任」、または「アボート。」
5.3.1. Successful Transfer
5.3.1. うまくいっている転送
After a successful data transfer, NETBLT closes the connection. When the sender is transmitting the last buffer of data, it sets a "last- buffer" flag on every DATA packet in the buffer. This means that no NEW data will be transmitted. The receiver knows the transfer has completed successfully when all of the following are true: (1) it has received DATA packets with a "last-buffer" flag set, (2) all its control messages have been acknowledged, and (3) it has no outstanding buffers with missing packets. At that point, the receiver is permitted to close its half of the connection. The sender knows the transfer has completed when the following are true:
うまくいっているデータ転送の後に、NETBLTは接続を終えます。 送付者がデータに関する最後のバッファを伝えているとき、それはバッファのあらゆるDATAパケットの上に「最後のバッファ」旗を設定します。 これは、NEWデータが全く送られないことを意味します。 以下のすべてが本当であるときに、受信機は、転送が首尾よく完成したのを知っています: (1) (3) 「最後のバッファ」旗のセットでDATAパケットを受けました、そして、(2) すべてのコントロールメッセージが承認されました、そして、それには、なくなったパケットがあるどんな傑出しているバッファもありません。 その時、受信機が半分の接続を終えることが許可されます。 以下が本当であるときに、送付者は、転送が完成したのを知っています:
Clark, Lambert, & Zhang [Page 13] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[13ページ]RFC998March
(1) it has transmitted DATA packets with a "last-buffer" flag set and (2) it has received OK messages for all its buffers. At that point, it "dallies" for a predetermined period of time before closing its half of the connection. If the NULL-ACK packet acknowledging the receiver's last OK message was lost, the receiver has time to retransmit the OK message, receive a new NULL-ACK, and recognize a successful transfer. The dally timer value MUST be based on the receiver's control timer value; it must be long enough to allow the receiver's control timer to expire so that the OK message can be re- sent. For this reason, all OK messages contain (in addition to new burst size and burst rate values), the receiver's current control timer value in milliseconds. The sender uses this value to compute its dally timer value.
(2) (1) 「最後のバッファ」旗のセットでDATAパケットを送信しました、そして、すべてのバッファへのOKメッセージを受け取りました。 その時、半分の接続を終える前に、それは予定された期間の間、「ふざけます」。 受信機には、NULL-ACKパケットであるなら、受信機の最後のOKメッセージを承認するのは失われて、OKメッセージを再送して、新しいNULL-ACKを受けて、うまくいっている転送を認識する時間があります。 タイマ値をぶらぶらつぶしてください。受信機のコントロールタイマ価値に基づかなければなりません。 それはOKメッセージを再送ることができるように受信機の制御タイマが期限が切れるのを許容できるくらい長くなければなりません。 この理由ですべてのOKメッセージが含んでいる、(新しい放出量と炸裂レート値に加えて)ミリセカンドで表現される受信機の現在のコントロールタイマ価値。 送付者が計算するのにこの値を使用する、それ、タイマ値をぶらぶらつぶしてください。
Since the dally timer value may be quite large, the receiving NETBLT is permitted to "short-circuit" the sending NETBLT's dally timer by transmitting a DONE packet. The DONE packet is transmitted when the receiver knows the transfer has been successfully completed. When the sender receives a DONE packet, it is allowed to clear its dally timer and close its half of the connection immediately. The DONE packet is not reliably transmitted, since failure to receive it only means that the sending NETBLT will take longer time to close its half of the connection (as it waits for its dally timer to clear)
タイマ値をぶらぶらつぶしてください。以来、かなり大きいです、受信NETBLTがDONEパケットを伝えることによって送付NETBLTのものがぶらぶらつぶす「短絡」タイマに受入れられるということであってもよいです。 受信機が、転送が首尾よく終了したのを知っているとき、DONEパケットは伝えられます。 送付者がDONEパケットを受けるとき、クリアすることができる、それ、タイマをぶらぶらつぶしてください、そして、すぐに、半分の接続を終えてください。 DONEパケットは確かに伝えられません、それを受けない場合発信しているNETBLTが半分の接続を終えるには、より長い時間がかかることを意味するだけであるので(待っている、それ、ふざける、きれいにするタイマ)
5.3.2. Client QUIT
5.3.2. クライアントはやめました。
During a NETBLT transfer, one client may send a QUIT packet to the other if it thinks that the other client is malfunctioning. Since the QUIT occurs at a client level, the QUIT transmission can only occur between buffer transmissions. The NETBLT receiving the QUIT packet can take no action other than immediately notifying its client and transmitting a QUITACK packet. The QUIT sender must time out and retransmit until a QUITACK has been received or its death timer expires. The sender of the QUITACK dallies before quitting, so that it can respond to a retransmitted QUIT.
NETBLT転送の間、それが、もう片方のクライアントが誤動作していると思うなら、1人のクライアントがQUITパケットをもう片方に送るかもしれません。 QUITがクライアントレベルで起こるので、QUITトランスミッションはバッファトランスミッションの間に起こることができるだけです。 QUITパケットを受けるNETBLTは、クライアントに通知して、QUITACKパケットを伝えながら、すぐに以外の行動を全く取ることができません。 そして、QUIT送付者必須タイムアウト、QUITACKを受け取ったか、または死亡タイマが期限が切れるまで、再送してください。 QUITACKの送付者は再送されたQUITに応じることができるようにやめる前に、ふざけます。
5.3.3. NETBLT ABORT
5.3.3. NETBLTは中止になります。
An ABORT takes place when a NETBLT layer thinks that it or its opposite is malfunctioning. Since the ABORT originates in the NETBLT layer, it can be sent at any time. The ABORT implies that the NETBLT layer is malfunctioning, so no transmit reliability is expected, and the sender can immediately close it connection.
NETBLT層が、それかその正反対が誤動作していると思うとき、ABORTは行われます。 ABORTがNETBLT層で起こるので、いつでも、それを送ることができます。 NETBLT層が誤動作しているのでいいえが信頼性を伝えるのは予想されます、そして、送付者はすぐに、それを閉じることができます。ABORTが含意する、接続。
6. Protocol Layering Structure
6. プロトコルレイヤリング構造
NETBLT is implemented directly on top of the Internet Protocol (IP). It has been assigned an official protocol number of 30 (decimal).
NETBLTは直接インターネットプロトコル(IP)の上で実装されます。 公式のプロトコル番号の30(10進)をそれに割り当ててあります。
Clark, Lambert, & Zhang [Page 14] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[14ページ]RFC998March
7. Planned Enhancements
7. 計画された増進
As currently specified, NETBLT has no algorithm for determining its rate-control parameters (burst rate, burst size, etc.). In initial performance testing, these parameters have been set by the person performing the test. We are now exploring ways to have NETBLT set and adjust its rate-control parameters automatically.
現在指定されるように、NETBLTには速度制御パラメタ(レート、放出量などを押し破く)を決定するためのアルゴリズムが全くありません。 初期の性能テストで、これらのパラメタはテストを実行している人によって設定されました。 私たちは今、NETBLTが自動的に速度制御パラメタを設定して、調整するのを持つ方法を探っています。
8. Packet Formats
8. パケット・フォーマット
NETBLT packets are divided into three categories, all of which share a common packet header. First, there are those packets that travel only from data sender to receiver; these contain the high- acknowledged-sequence-numbers which the receiver uses for control message transmission reliability. These packets are the NULL-ACK, DATA, and LDATA packets. Second, there is a packet that travels only from receiver to sender. This is the CONTROL packet; each CONTROL packet can contain an arbitrary number of control messages (GO, OK, or RESEND), each with its own sequence number. Finally, there are those packets which either have special ways of insuring reliability, or are not reliably transmitted. These are the OPEN, RESPONSE, REFUSED, QUIT, QUITACK, DONE, KEEPALIVE, and ABORT packets. Of these, all save the DONE packet can be sent by both sending and receiving NETBLTs.
NETBLTパケットは3つのカテゴリに分割されます。そのすべてが一般的なパケットのヘッダーを共有します。 まず最初に、データ送付者だけから受信機まで移動するそれらのパケットがあります。 これらは受信機がコントロールメッセージトランスミッションの信頼性に使用する高い承認された一連番号を含んでいます。 これらのパケットは、NULL-ACKと、DATAと、LDATAパケットです。 2番目に、受信機だけから送付者まで移動するパケットがあります。 これはCONTROLパケットです。 それぞれのCONTROLパケットはコントロールメッセージ(GO、OKかRESEND)の特殊活字の数字を含むことができます、それぞれそれ自身の一連番号で。 最終的に、信頼性を保障する特別な方法を持っているか、または確かに伝えられないそれらのパケットがあります。 これらは、オープンと、RESPONSEと、REFUSEDと、QUITと、QUITACKと、DONEと、KEEPALIVEと、ABORTパケットです。 これらでは、すべてがともにNETBLTsを送って、受けることによってパケットを送ることができるDONEを取っておきます。
All packets are "longword-aligned", i.e. all packets are a multiple of 4 bytes in length and all 4-byte fields start on a longword boundary. All arbitrary-length string fields are terminated with at least one null byte, with extra null bytes added at the end to create a field that is a multiple of 4 bytes long.
すべてのパケットが「ロングワードによって並べられます」、そして、すなわちすべてのパケットが長さが4バイトの倍数です、そして、すべての4バイトの分野がロングワード限界を始めます。 すべての任意の長さの文字列欄がヌル少なくとも1バイトで終えられます、付加的なヌルバイトが終わりに4バイト長の倍数である分野を作成するために加えられている状態で。
Clark, Lambert, & Zhang [Page 15] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[15ページ]RFC998March
Packet Formats for NETBLT
NETBLTのためのパケット・フォーマット
OPEN (type 0) and RESPONSE (type 1):
(タイプ0)と応答(1をタイプする)を開いてください:
1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
| Connection Unique ID |
+---------------+---------------+---------------+---------------+
| Buffer Size |
+---------------+---------------+---------------+---------------+
| Transfer Size |
+---------------+---------------+---------------+---------------+
| DATA packet size | Burst Size |
+---------------+---------------+---------------+---------------+
| Burst Rate | Death Timer Value |
+---------------+---------------+---------------+---------------+
| Reserved (MBZ) |C|M| Maximum # Outstanding Buffers |
+---------------+---------------+---------------+---------------+
| Client String ...
+---------------+---------------+---------------
Longword Alignment Padding |
---------------+-------------------------------+
1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +---------------+---------------+---------------+---------------+ | チェックサム| バージョン| タイプ| +---------------+---------------+---------------+---------------+ | 長さ| 地方のポート| +---------------+---------------+---------------+---------------+ | 外国ポート| ロングワード整列詰め物| +---------------+---------------+---------------+---------------+ | 接続のユニークなID| +---------------+---------------+---------------+---------------+ | バッファサイズ| +---------------+---------------+---------------+---------------+ | 転送サイズ| +---------------+---------------+---------------+---------------+ | DATAパケットサイズ| 放出量| +---------------+---------------+---------------+---------------+ | 炸裂率| 死亡タイマ価値| +---------------+---------------+---------------+---------------+ | 予約されます(MBZ)。|C|M| 最大の#傑出しているバッファ| +---------------+---------------+---------------+---------------+ | クライアントストリング… +---------------+---------------+--------------- ロングワード整列詰め物| ---------------+-------------------------------+
Checksum: packet checksum (algorithm is described in the section "Connection Setup")
チェックサム: パケットチェックサム(アルゴリズムは「接続設定」というセクションで説明されます)
Version: the NETBLT protocol version number
バージョン: NETBLTプロトコルバージョン番号
Type: the NETBLT packet type number (OPEN = 0, RESPONSE = 1, etc.)
以下をタイプしてください。 NETBLTパケット形式数(オープン=0、RESPONSE=1など)
Length: the total length (NETBLT header plus data, if present) of the NETBLT packet in bytes
長さ: 全長、(NETBLTヘッダープラスデータ、存在しているならバイトで表現されるNETBLTパケット
Local Port: the local NETBLT's 16-bit port number
地方のポート: 地方のNETBLTの16ビットのポートナンバー
Foreign Port: the foreign NETBLT's 16-bit port number
外国ポート: 外国NETBLTの16ビットのポートナンバー
Connection UID: the 32 bit connection UID specified in the section "Connection Setup".
接続UID: 32ビットの接続UIDは「接続設定」というセクションで指定しました。
Buffer size: the size in bytes of each NETBLT buffer (save the last)
サイズをバッファリングしてください: それぞれのNETBLTバッファのバイトで表現されるサイズ(最終を節約します)
Clark, Lambert, & Zhang [Page 16] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[16ページ]RFC998March
Transfer size: (optional) the size in bytes of the transfer.
サイズを移してください: (任意)です。 転送のバイトで表現されるサイズ。
This is for client information only; the receiving NETBLT should NOT make use of it.
これはクライアント情報だけのためのものです。 受信NETBLTはそれを利用するはずがありません。
Data packet size: length of each DATA packet in bytes
データ・パケットサイズ: バイトで表現されるそれぞれのDATAパケットの長さ
Burst Size: Number of DATA packets in a burst
サイズを押し破いてください: 炸裂における、DATAパケットの数
Burst Rate: Transmit time in milliseconds of a single burst
レートを押し破いてください: シングル・バーストのミリセカンドで時間を伝えてください。
Death timer: Packet sender's death timer value in seconds
死亡タイマ: 秒のパケット送付者の死亡タイマ価値
"M": the transfer mode (0 = READ, 1 = WRITE)
「M」: 転送モード(=が読んだ0、1=は書きます)
"C": the DATA packet data checksum flag (0 = do not checksum DATA packet data, 1 = do)
「C」: DATAパケットデータチェックサム旗(チェックサムDATAパケットデータではなく、=がする0、=がそうする1)
Maximum Outstanding Buffers: maximum number of buffers that can be transferred before waiting for an OK message from the receiving NETBLT.
最大の傑出しているバッファ: OKメッセージを待つ前に受信NETBLTから移すことができる最大数に関するバッファ。
Client string: an arbitrary, null-terminated, longword-aligned string for use by NETBLT clients.
クライアントストリング: NETBLTクライアントによる使用のために任意の、そして、ヌルで終えられて、ロングワードで並べられたストリング。
KEEPALIVE (type 2), QUITACK (type 4), and DONE (type 11)
QUITACK(4をタイプする)であって、されたKEEPALIVE(2をタイプします)(タイプ11)
1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +---------------+---------------+---------------+---------------+ | チェックサム| バージョン| タイプ| +---------------+---------------+---------------+---------------+ | 長さ| 地方のポート| +---------------+---------------+---------------+---------------+ | 外国ポート| ロングワード整列詰め物| +---------------+---------------+---------------+---------------+
Clark, Lambert, & Zhang [Page 17] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[17ページ]RFC998March
QUIT (type 3), ABORT (type 5), and REFUSED (type 10)
(タイプ3)、アボート(5をタイプする)をやめて、拒否します。(タイプ10)
1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
| Reason for QUIT/ABORT/REFUSE...
+---------------+---------------+---------------
Longword Alignment Padding |
---------------+-------------------------------+
1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +---------------+---------------+---------------+---------------+ | チェックサム| バージョン| タイプ| +---------------+---------------+---------------+---------------+ | 長さ| 地方のポート| +---------------+---------------+---------------+---------------+ | 外国ポート| ロングワード整列詰め物| +---------------+---------------+---------------+---------------+ | 推論する、やめるか、中止になる、または拒否してください… +---------------+---------------+--------------- ロングワード整列詰め物| ---------------+-------------------------------+
DATA (type 6) and LDATA (type 7):
データ(6をタイプする)とLDATA(7をタイプします):
1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
| Buffer Number |
+---------------+---------------+---------------+---------------+
| High Consecutive Seq Num Rcvd | Packet Number |
+---------------+---------------+---------------+---------------+
| Data Area Checksum Value | Reserved (MBZ) |L|
+---------------+---------------+---------------+---------------+
1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +---------------+---------------+---------------+---------------+ | チェックサム| バージョン| タイプ| +---------------+---------------+---------------+---------------+ | 長さ| 地方のポート| +---------------+---------------+---------------+---------------+ | 外国ポート| ロングワード整列詰め物| +---------------+---------------+---------------+---------------+ | バッファ数| +---------------+---------------+---------------+---------------+ | 高い連続したSeqヌムRcvd| パケット番号| +---------------+---------------+---------------+---------------+ | データ領域チェックサム価値| 予約されます(MBZ)。|L| +---------------+---------------+---------------+---------------+
Buffer number: a 32 bit unique number assigned to every buffer. Numbers are monotonically increasing.
バッファ数: あらゆるバッファに割り当てられた32ビットのユニークな数。 数は単調に増加しています。
High Consecutive Sequence Number Received: Highest control message sequence number below which all sequence numbers received are consecutive.
高い連続した一連番号は受けました: 一連番号が受けたすべてが連続している最も高い規制メッセージ通番。
Packet number: monotonically increasing DATA packet identifier
パケット番号: DATAパケット識別子を単調に増強します。
Data Area Checksum Value: Checksum of the DATA packet's data. Algorithm used is the same as that used to compute checksums of other NETBLT packets.
データ領域チェックサム価値: DATAパケットのデータのチェックサム。 使用されるアルゴリズムは他のNETBLTパケットのチェックサムを計算するのに使用されるそれと同じです。
"L" is a flag set when the buffer that this DATA packet belongs to is the last buffer in the transfer.
このDATAパケットが属すバッファが転送で最後のバッファであるときに、「L」は旗のセットです。
Clark, Lambert, & Zhang [Page 18] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[18ページ]RFC998March
NULL-ACK (type 8)
ヌルACK(タイプ8)
1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
| High Consecutive Seq Num Rcvd | New Burst Size |
+---------------+---------------+---------------+---------------+
| New Burst Rate | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +---------------+---------------+---------------+---------------+ | チェックサム| バージョン| タイプ| +---------------+---------------+---------------+---------------+ | 長さ| 地方のポート| +---------------+---------------+---------------+---------------+ | 外国ポート| ロングワード整列詰め物| +---------------+---------------+---------------+---------------+ | 高い連続したSeqヌムRcvd| 新しい放出量| +---------------+---------------+---------------+---------------+ | 新しい炸裂率| ロングワード整列詰め物| +---------------+---------------+---------------+---------------+
High Consecutive Sequence Number Received: same as in DATA/LDATA packet
高い連続した一連番号は受けました: DATA/LDATAパケットと同じです。
New Burst Size: Burst size as negotiated from value given by receiving NETBLT in OK message
新しい放出量: OKメッセージでNETBLTを受けることによって与えられた値から交渉される放出量
New burst rate: Burst rate as negotiated from value given by receiving NETBLT in OK message. Value is in milliseconds.
新しい炸裂率: OKメッセージでNETBLTを受けることによって与えられた値から交渉されるようにレートを押し破いてください。 値がミリセカンドであります。
CONTROL (type 9):
制御してください(9をタイプしてください):
1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +---------------+---------------+---------------+---------------+ | チェックサム| バージョン| タイプ| +---------------+---------------+---------------+---------------+ | 長さ| 地方のポート| +---------------+---------------+---------------+---------------+ | 外国ポート| ロングワード整列詰め物| +---------------+---------------+---------------+---------------+
Followed by any number of messages, each of which is longword aligned, with the following formats:
いろいろなメッセージがあとに続いています:それはそれぞれ以下の形式に並べられたロングワードです。
GO message (type 0):
GOメッセージ(0をタイプします):
1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+---------------+---------------+---------------+---------------+
| Type | Word Padding | Sequence Number |
+---------------+---------------+---------------+---------------+
| Buffer Number |
+---------------+---------------+---------------+---------------+
1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +---------------+---------------+---------------+---------------+ | タイプ| Word詰め物| 一連番号| +---------------+---------------+---------------+---------------+ | バッファ数| +---------------+---------------+---------------+---------------+
Type: message type (GO = 0, OK = 1, RESEND = 2)
以下をタイプしてください。 メッセージタイプ(0、OK=1と等しくしに行ってください、そして、=2を再送してください)
Clark, Lambert, & Zhang [Page 19] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[19ページ]RFC998March
Sequence number: A 16 bit unique message number. Sequence numbers must be monotonically increasing, starting from 1.
一連番号: 16ビットのユニークなメッセージ番号。 1から始める場合、一連番号は単調に増加しなければなりません。
Buffer number: as in DATA/LDATA packet
バッファ数: DATA/LDATAパケット
OK message (type 1):
メッセージ(1をタイプする)を承認してください:
1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+---------------+---------------+---------------+---------------+
| Type | Word Padding | Sequence Number |
+---------------+---------------+---------------+---------------+
| Buffer Number |
+---------------+---------------+---------------+---------------+
| New Offered Burst Size | New Offered Burst Rate |
+---------------+---------------+---------------+---------------+
| Current control timer value | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +---------------+---------------+---------------+---------------+ | タイプ| Word詰め物| 一連番号| +---------------+---------------+---------------+---------------+ | バッファ数| +---------------+---------------+---------------+---------------+ | 新しい提供された放出量| 新しい提供された炸裂率| +---------------+---------------+---------------+---------------+ | 現在のコントロールタイマ価値| ロングワード整列詰め物| +---------------+---------------+---------------+---------------+
New offered burst size: burst size for subsequent buffer transfers, possibly based on performance information for previous buffer transfers.
新しい提供された放出量: 前のバッファが移されるので、ことによると性能情報に基づいたその後のバッファ転送のためにサイズを押し破いてください。
New offered burst rate: burst rate for subsequent buffer transfers, possibly based on performance information for previous buffer transfers. Rate is in milliseconds.
新しい提供された炸裂率: 前のバッファが移されるので、ことによると性能情報に基づいたその後のバッファ転送のためにレートを押し破いてください。 レートがミリセカンドであります。
Current control timer value: Receiving NETBLT's control timer value in milliseconds.
現在のコントロールタイマ価値: ミリセカンドでNETBLTのコントロールタイマ価値を受けます。
RESEND Message (type 2):
メッセージを再送してください(2をタイプしてください):
1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+---------------+---------------+---------------+---------------+
| Type | Word Padding | Sequence Number |
+---------------+---------------+---------------+---------------+
| Buffer Number |
+---------------+---------------+---------------+---------------+
| Number of Missing Packets | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
| Packet Number (2 bytes) ...
+---------------+---------------+----------
| Padding (if necessary) |
-----------+---------------+---------------+
1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +---------------+---------------+---------------+---------------+ | タイプ| Word詰め物| 一連番号| +---------------+---------------+---------------+---------------+ | バッファ数| +---------------+---------------+---------------+---------------+ | なくなったパケットの数| ロングワード整列詰め物| +---------------+---------------+---------------+---------------+ | パケットNumber(2バイト)… +---------------+---------------+---------- | (必要なら)そっと歩くこと。| -----------+---------------+---------------+
Packet number: the 16 bit data packet identifier found in each DATA packet.
パケット番号: 16はそれぞれのDATAパケットで見つけられたデータ・パケット識別子に噛み付きました。
Clark, Lambert, & Zhang [Page 20] RFC 998 March 1987
1987年のクラーク、ランバート、およびチャン[20ページ]RFC998March
NOTES:
注意:
<1> When the buffer size is large, the variances in the round trip delays of many packets may cancel each other out; this means the variance value need not be very big. This expectation will be explored in further testing.
<、バッファサイズであるときに、1>が大きい、多くのパケットの周遊旅行遅れにおける変化は互いを相殺するかもしれません。 これは、変化の値がそれほど大きい必要はないことを意味します。 この期待は追加検査で調査されるでしょう。
Clark, Lambert, & Zhang [Page 21]
クラーク、ランバート、およびチャン[21ページ]
一覧
スポンサーリンク
