RFC969 日本語訳
0969 NETBLT: A bulk data transfer protocol. D.D. Clark, M.L. Lambert,L. Zhang. December 1985. (Format: TXT=40040 bytes) (Obsoleted by RFC0998) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group David D. Clark
Request for Comments: 969 Mark L. Lambert
Lixia Zhang
M. I. T. Laboratory for Computer Science
December 1985
コメントを求めるワーキンググループデヴィッドD.クラークの要求をネットワークでつないでください: 969 マークL.ランバートLixiaチャンM.I.T.コンピュータ科学研究所1985年12月
NETBLT: A Bulk Data Transfer Protocol
NETBLT: バルク・データ転送プロトコル
1. STATUS OF THIS MEMO
1. このメモの状態
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the NETBLT protocol. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. Distribution of this memo is unlimited.
このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 これはNETBLTプロトコルの予備的な討論です。 それは、議論とコメントのために発行されて、規格を構成しません。 提案が変化するとき、このドキュメントの実装は教えられません。 このメモの分配は無制限です。
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 structured to provide maximum throughput over a wide variety of networks.
NETBLT(ネットワークBlock Transfer)は平らなプロトコルがコンピュータの間の多量のデータの迅速な移転のために意図した輸送です。 それが信頼できる転送を供給して、流れは、制御して、さまざまなネットワークの上に最大のスループットを提供するために構造化されます。
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 arbitrarily 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, but 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 been transmitted, the receiving NETBLT checks to see that all packets in that buffer have arrived. 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 buffer arrived, and the sender prepares and sends the next buffer in the
最も簡単なフォームでは、NETBLT転送は以下の通り働いています。 送付クライアントは、データに関するバッファをロードして、それを移すためにNETBLT層まで電話をします。 NETBLT層は、パケットにバッファを壊れさせて、インターネットデータグラムのネットワークの向こう側にこれらのパケットを送ります。受信NETBLT層は受信クライアントによって提供された合っているバッファにこれらのパケットを積み込みます。 バッファにおける最後のパケットが伝えられたとき、受信NETBLTは、そのバッファのすべてのパケットが到着したのを確実にするためにチェックします。 いくつかのパケットがなくなるなら、受信NETBLTは、それらが再送されるよう要求します。 バッファが完全に伝えられたとき、受信クライアントはNETBLT層のそばで通知されます。 受信クライアントは、バッファを処分して、より多くのデータを受け取るために新しいバッファを提供します。 受信NETBLTが、バッファが到着したことを送付者に通知して、送付者は、次のバッファを中に準備して、送ります。
Clark & Lambert & Zhang [Page 1]
クラーク、ランバート、およびチャン[1ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
same manner. This continues until all buffers have been sent, at which time the sender notifies the receiver that the transmission has been completed. The connection is then closed.
同じ方法。 これは送付者が、どの時にトランスミッションが終了したことを受信機に通知するかときすべてのバッファを送るまで続きます。 そして、接続は閉店します。
As described above, the NETBLT protocol is "lock-step"; action is halted after a buffer is transmitted, and begins again after confirmation is received from the receiver of data. NETBLT provides for multiple buffering, in which several buffers can be transmitted concurrently. Multiple buffering makes packet flow essentially continuous and can improve performance markedly.
上で説明されるように、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, reliability, and connection management. The final sections describe the protocol format.
このドキュメントの残りは詳細にNETBLTについて説明します。 次のセクションは多くのプロトコル機能の後ろで哲学について説明します: packetization、フロー制御、信頼性、および接続管理。 最後のセクションはプロトコル形式について説明します。
3. BUFFERS AND PACKETS
3. バッファとパケット
NETBLT is designed to permit transfer of an essentially arbitrary amount of data between two clients. During connection setup the sending NETBLT can optionally inform the receiving NETBLT of the transfer size; the maximum transfer length is imposed by the field width, and 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 receiver accepts data until told by the sender that the transfer is complete.
NETBLTは、2人のクライアントの間の本質的には任意のデータ量の転送を可能にするように設計されています。 接続設定の間、発信しているNETBLTは転送サイズについて任意に受信NETBLTに知らせることができます。 最大の転送の長さは、欄の幅によって課されて、32バイト2**です。 この限界はどんな実用化も可能にするべきです。 転送サイズ・パラメータは受信クライアントの使用のためのものです。 受信NETBLTはそれの無駄をします。 転送が完全であると送付者によって言われるまで、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 breaking up data into buffers on byte boundaries.
クライアントは送られるデータをバッファに終えなければなりません。 各バッファは最後のバッファ以外の同じサイズであるに違いありません。 接続設定の間、送受信NETBLTsはクライアントによって提供された限界に基づいてバッファサイズを交渉します。 バッファサイズがバイトだけであります。 クライアントはバイト境界のバッファにデータを終えるのに責任があります。
NETBLT has been designed and should be implemented to work with buffers of arbitrary 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 of its own 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
NETBLTは最小それ自身のメモリを必要とするように設計されています、クライアントができるだけ緩衝記憶装置において多くのメモリを割り当てるのを許容して。 特に、NETBLTは「再-トランスミッション」目的のためにバッファ写しを取っておきません。 代わりに、再送されるべきデータは直接再コピーされます。
Clark & Lambert & Zhang [Page 2]
クラーク、ランバート、およびチャン[2ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
from the client buffer. This does mean that the client cannot release buffer storage piece by piece as the buffer is sent, but this has not proved a problem in preliminary NETBLT implementations.
クライアントバッファから。 バッファを送るとき、クライアントが断片で緩衝記憶装置断片をリリースできないことを意味しますが、これは予備のNETBLT実装における問題を立証していません。
Buffers are broken down by the NETBLT layer into sequences of DATA packets. As with the buffer size, the packet size is negotiated between the sending and receiving NETBLTs during connection setup. Unlike buffer size, packet size is visible only to the NETBLT layer.
バッファはNETBLT層のそばでDATAパケットの系列へ砕けています。 バッファサイズのように、パケットサイズは接続設定の間、送受信NETBLTsの間で交渉されます。 バッファサイズと異なって、パケットサイズはNETBLT層だけに目に見えます。
All DATA packets save the last packet in a buffer must be the same size. Packets should be as large as possible, since in most cases (including the preliminary protocol implementation) performance is directly related to packet size. At the same time, the packets should not be so large as to cause Internet fragmentation, since this normally causes performance degrada- tion.
パケットがバッファで最後のパケットを保存するすべてのDATAが同じサイズであるに違いありません。 パケットはできるだけ大きいはずです、性能が多くの場合(予備のプロトコル実装を含んでいる)直接パケットサイズに関連するので。 同時に、パケットは原因インターネット断片化に関してそれほど大きいはずがありません、これが通常性能degrada- tionを引き起こすので。
All buffers save the last buffer must be the same size; obviously 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 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 while it is in progress.
送受信NETBLTsはバッファのデータを送ります。 クライアントフロー制御がしたがって、バッファレベルにあります。 バッファを伝えることができる前に、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 packets to be lost. Similarly, a slow gateway or intermediate network could cause packets to collect and overflow network packet
バッファが伝えられている間に起こることができたいくつかのフロー制御問題があります。 発信しているNETBLTが受信NETBLTがそれを処理できるより速くデータを移しているなら、未加工のパケットをバッファリングする受信機の性能ははみ出すかもしれません、パケットが失われることを引き起こして。 同様に、遅いゲートウェイか中間ネットワークが集めるパケットとオーバーフローネットワークパケットを引き起こす場合がありました。
Clark & Lambert & Zhang [Page 3]
クラーク、ランバート、およびチャン[3ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
buffer space. Packets will then be lost within the network, degrading performance. This problem is particularly acute for NETBLT because NETBLT buffers will generally be quite large, and therefore composed of many packets.
スペースをバッファリングしてください。 そして、性能を下げて、パケットはネットワークの中で失われるでしょう。 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 change.
パケットフロー制御への伝統的な解決はウィンドウシステムです。(そこでは、送信側が一度にある数のパケットだけを送ることが許可されています)。 残念ながら、窓を使用するフロー制御は、少ないスループットをもたらす傾向があります。 Windowsをホストとゲートウェイからはみ出すのを避けるために小さく保たなければならなくて、容易にアップデートできません、終わりから終わりへの交換が各変化に必要であるので。
To permit high throughput over a variety of networks and gateways of differing speeds, NETBLT uses a novel flow control ethod: 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は目新しいフロー制御ethodを使用します: コントロールを評定してください。 通信速度は接続設定とそれぞれのバッファトランスミッションの後に送受信NETBLTsによって交渉されます。 送付者は、交渉されたレートを維持するのに受信機からのメッセージよりむしろタイマを使用します。
In its simplest form, rate control specifies a minimum time period per packet transmission. This can cause performance problems for several reasons: 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, which degrades 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 negotiated interval, then sends another burst. In this way, the overhead decreases by a factor of the burst size, and the per-burst transmission rate is large enough that timing mechanisms will work properly. The 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 rate per packet.
ソリューションは単一のパケットよりむしろパケットのグループの通信速度を制御することです。 送付者は、交渉された間隔の上にパケットの炸裂を伝えて、次に、別の炸裂を送ります。 このように、オーバーヘッドは放出量の要素で下がります、そして、1バースト伝送あたりのレートはタイミングメカニズムが適切に動作するほど大きいです。 したがって、NETBLTの速度制御には、(放出量)/(レートを押し破きます)に従った2つの部品、放出量、および炸裂率が平均した通信速度への1パケットあたりの同輩にあります。
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 those gateways and networks intermediate to the transfer. 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
パケットサイズは128バイトと同じくらい小さいことができます。 パケットがこれほど小さいパフォーマンスは1パケットあたりの高い処理オーバヘッドのためにほとんどいつも悪いです。 適切な性能には、576バイトのデフォルトインターネットプロトコルパケットサイズさえ十分ほとんど大きくはありません。 most
Clark & Lambert & Zhang [Page 4]
クラーク、ランバート、およびチャン[4ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
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, degrading performance.
ネットワークは1バイトか2,000バイトよりはるかに大きいパケットサイズをサポートしません、そして、また、中間ネットワークの上を旅行するとき、このサイズのパケットは断片化できます、性能を下げて。
The size of a NETBLT buffer is limited only by the amount of memory available to a client. Theoretically, buffers of 100K bytes or more are possible. This would mean the transmission of 50 to 100 packets per buffer.
NETBLTバッファのサイズはクライアントにとって、有効なメモリー容量だけによって制限されます。 理論的に、100Kのバイトか以上のバッファは可能です。 これは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. On most modern operating systems, a burst size of between five and ten packets should reduce the overhead to an acceptable level. In fact, a preliminary NETBLT implementation for the IBM PC/AT sends packets in bursts of five. It could send more, but is limited by 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 60 to 100 milliseconds have been tried on the preliminary NETBLT implementation with good results within a single local-area network. This value clearly depends on the network bandwidth and packet buffering available.
炸裂率は送付者のタイミングメカニズムの粒状、および一部受信機とどんな中間ゲートウェイの処理速度によっても一部測定されます。 また、それは直接放出量に関連します。 ただ一つのローカル・エリア・ネットワークの中で予備のNETBLT実装で良い結果で60〜100ミリセカンドの炸裂率を試みてあります。 この値は明確に利用可能なネットワーク回線容量とパケットバッファリングであることに依存します。
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 with its open 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 only by making them more restrictive. The modified parameters are then sent back to the active end in the response message. In addition, the burst size and burst rate can 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 a pair of burst size and burst rate values in the OK message. The sender compares these values with the values it can support. Again, it may then modify any of the parameters only by making them more restrictive. The modified parameters are then communicated to the receiver in a NULL-ACK packet, described later.
すべてのNETBLTフロー制御パラメタ(パケットサイズ(バッファサイズ)は、サイズを押し破いて、レートを押し破いた)が接続設定の間、交渉されます。 すべてのパラメタに、交渉プロセスは同じです。 接続(アクティブな終わり)を開始するクライアントは、各パラメタのために開いている接続要求と共に1セットの値を提案して、送ります。 もう片方のクライアント(受け身の終わり)はそれがサポートすることができる最も高い性能値とこれらの値を比べます。 そして、受け身の終わりは、単にそれらをより制限するようにすることによって、パラメタのいずれも変更できます。 そして、応答メッセージへのアクティブな終わりは変更されたパラメタに送り返されます。 さらに、それぞれのバッファトランスミッションの後に前のバッファを移すのから観測された性能に応じて転送レートを調整するために放出量と炸裂率を再交渉できます。 犠牲者はOKメッセージの1組の放出量と炸裂レート値を送ります。 送付者はそれがサポートすることができる値とこれらの値を比べます。 そして、一方、それは、単にそれらをより制限するようにすることによって、パラメタのいずれも変更するかもしれません。 そして、変更されたパラメタは後で説明されたNULL-ACKパケットの受信機に伝えられます。
Clark & Lambert & Zhang [Page 5]
クラーク、ランバート、およびチャン[5ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
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. RELIABILITY
5. 信頼性
Each NETBLT transfer has three stages, connection setup, data transfer, and connection close. Each stage must be completed reliably; methods for doing this are described below.
それぞれのNETBLT転送には、3つのステージ、接続設定、データ転送、および接続が近くにあります。 各ステージを確かに完成しなければなりません。 これをするためのメソッドは以下で説明されます。
5.1. Connection Setup
5.1. 接続設定
A NETBLT connection is set up by an exchange of two packets
between the active client and the passive client. Note that
either client can send or receive data; the words "active" and
"passive" are only used to differentiate the client initiating the
connection process from the client responding to the connection
request. The first packet sent is an OPEN packet; the passive end
acknowledges the OPEN packet by sending a RESPONSE packet. After
these two packets have been exchanged, the transfer can begin.
NETBLT接続は活発なクライアントと受け身のクライアントの間の2つのパケットの交換でセットアップされます。 どちらのクライアントもデータを送るか、または受け取ることができることに注意してください。 単語「アクティブ」、そして、「受動態」はクライアントの応じるのと接続プロセスを開始するクライアントを単に接続要求に区別するのにおいて使用されています。 送られた最初のパケットはオープンパケットです。 受け身の終わりは、RESPONSEパケットを送ることによって、オープンパケットを承認します。 これらの2つのパケットを交換した後に、転送は始まることができます。
As discussed in the previous section, the OPEN and RESPONSE
packets are used to negotiate flow control parameters. Other
parameters used in the transfer of data are also negotiated.
These parameters are (1) the maximum number of buffers that can be
sending at any one time (this permits multiple buffering and
higher throughput) and (2) whether or not DATA/LDATA 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.
NETBLT uses the same checksumming algorithm as TCP uses.
前項で議論するように、オープンとRESPONSEパケットはフロー制御パラメタを交渉するのに使用されます。 また、データ転送に使用される他のパラメタは交渉されます。 DATA/LDATAパケットデータがchecksummedされるか否かに関係なく、これらのパラメタは、(1) いかなる時も(これは複数のバッファリングしていて、より高いスループットを可能にする)発信できるバッファの最大数と(2)です。 NETBLT、自動的にチェックサム、すべての非DATA/LDATAパケット。 交渉されたチェックサム旗がTRUE(1)に設定されるなら、ヘッダーとDATA/LDATAパケットに関するデータの両方がchecksummedされます。 FALSE(0)に設定されるなら、ヘッダーだけがchecksummedされます。 NETBLTはTCP用途と同じchecksummingアルゴリズムを使用します。
Finally, each end transmits its death-timeout value in either the
OPEN or the RESPONSE packet. The death-timeout value will be used
to determine the frequency with which to send KEEPALIVE packets
during idle periods of an opened connection (death timers and
KEEPALIVE packets are described in the following section).
最終的に、各端はオープンかRESPONSEパケットのどちらかで死亡タイムアウト値を送ります。 死亡タイムアウト値は、開かれた接続の活動していない期間、パケットをKEEPALIVEに送る頻度を測定するのに使用されるでしょう(死亡タイマと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 16 bit port number.
アクティブな終わりは受け身の終わりが聴く16ビットのクライアント特有の「よく知られる」ポートナンバーを通して受け身のクライアントを指定します。 アクティブな終わりは32ビットのインターネット・アドレスと16ビットのポートナンバーを通してそれ自体を特定します。
In order to allow the active and passive ends to communicate
アクティブで受け身の終わりが交信するのを許容します。
Clark & Lambert & Zhang [Page 6]
クラーク、ランバート、およびチャン[6ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
miscellaneous useful information, an unstructured, variable-
length field is provided in OPEN and RESPONSE messages for an
client-specific information that may be required.
種々雑多な役に立つ情報、必要であるかもしれないクライアント特殊情報へのオープンとRESPONSEメッセージに不統一で、可変な長さの野原を提供します。
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 pre-determined maximum number of OPEN packets have been sent.
A similar scheme is used for the passive end when it sends a
RESPONSE packet. When a RESPONSE packet is received by the active
end, it clears its timer. The passive end's timer is cleared
either by receipt of a GO or a DATA packet, as described in the
section on data transfer.
タイマの使用で無くなっているオープンとRESPONSEパケットのための回復を供給します。 それがオープンパケットを送るとき、アクティブな終わりはタイマを設定します。 タイマが期限が切れるとき、何らかの予定された最大数のオープンパケットを送るまで別のオープンパケットを送ります。 同様の体系はそれがRESPONSEパケットを送る受け身の終わりに使用されます。 アクティブな終わりまでにRESPONSEパケットを受け取るとき、それはタイマをきれいにします。 受け身の終わりのタイマはGOの領収書かDATAパケットによってきれいにされます、データ転送のセクションで説明されるように。
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. A matching unique ID implies a duplicate
packet, and the packet is ignored. A non-matching unique ID must
be treated as an attempt to open a second connection between the
same port pair and must be rejected by sending an ABORT message.
オープンとRESPONSEパケットの複製を防ぐために、オープンパケットはRESPONSEパケットで返さなければならない32ビットの接続固有のIDを含んでいます。 これによって、創始者は現在の要求への応答を以前の接続要求への応答に間違えることができません(どんな2つのポートの間にはも、1つの接続しかあることができません)。 どんなオープンや仕向港がオープンな接続のものに合っているRESPONSEパケットでも、固有のIDをチェックします。 合っている固有のIDは写しパケットを含意します、そして、パケットは無視されます。 非合っている固有の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 into it. Once the GO message has been 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 which time the receiver sends an OK
message inside a CONTROL packet to the sender, 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 message, and repeats the process.
データ転送の最も簡単なモデルは以下の通り続きます。 送付クライアントはデータでいっぱいのバッファをセットアップします。 受信NETBLTは送付者へのCONTROLパケットにGOメッセージを送ります、それがもバッファをセットアップして、データをそれに受け取る準備ができているのを意味して。 いったんGOメッセージを受け取ると、一連のDATAパケットがLDATAパケットで続いたので、送付者はバッファを伝えます。 バッファにおける最後のパケットを受け取ったとき、受信機は受け取られなかったパケットのリストを含むCONTROLパケットにRESENDメッセージを送ります。 送付者はこれらのパケットを再送します。 どんななくなったパケット(受信機は、それの時に送付者へのCONTROLパケットにOKメッセージを送って、データを受け取るために別のバッファをセットアップして、別のGOメッセージを送る)もないまで、このプロセスは持続します。 送付者は、OKメッセージを受け取ったので、別のバッファをセットアップして、GOメッセージを待っていて、プロセスを繰り返します。
There are several obvious flaws with this scheme. First, if the
LDATA packet is lost, how does the receiver know when the buffer
has been transmitted? Second, what if the GO, OK, or RESEND
この体系があるいくつかの明白な欠点があります。 まず最初に、LDATAパケットが無くなるなら、バッファが伝えられた受信機はどのように知っていますか? GO、OKである、RESEND
Clark & Lambert & Zhang [Page 7]
クラーク、ランバート、およびチャン[7ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
messages are lost? The sender cannot act on a packet it has not
received, so the protocol will hang. Solutions for each of these
problems are presented below, and are based on two kinds of
timers, a data timer and a control timer.
メッセージは無くなっていますか? 送付者がそれが受けていないパケットに影響できないので、プロトコルは掛かるでしょう。 それぞれのこれらの問題のためのソリューションは、以下に提示されて、2種類のタイマ、データタイマ、および制御タイマに基づいています。
NETBLT solves the LDATA packet loss problem by using a data timer
at the receiving end. When the first DATA packet in a buffer
arrives, the receiving NETBLT sets its data timer; at the same
time, it clears its control timer, described below. If the data
timer expires, the receiving end assumes the buffer has been
transmitted and all missing packets lost. It then sends a RESEND
message containing a list of the missing packets.
NETBLTは、犠牲者にデータタイマを使用することによって、LDATAパケット損失問題を解決します。 バッファにおける最初のDATAパケットが到着するとき、受信NETBLTはデータタイマを設定します。 同時に、それは以下で説明された制御タイマをきれいにします。 データタイマが期限が切れるなら、犠牲者はバッファが伝えられて、すべてのなくなったパケットが損をしたと仮定します。 そして、それはなくなったパケットのリストを含むRESENDメッセージを送ります。
NETBLT solves the second problem, that of missing OK, GO, and
RESEND messages, through use of a control timer. The receiver can
send one or more control messages (OK, GO, or RESEND) within a
single CONTROL packet. Whenever the receiver sends a control
packet, it sets a control timer (at the same time it clears its
data timer, if one has been set).
NETBLTは制御タイマの使用で2番目の問題、OKが恋しいことのもの、GO、およびRESENDメッセージを解決します。 受信機は単一のCONTROLパケットの中で1つ以上のコントロールメッセージ(OK、GO、またはRESEND)を送ることができます。 受信機がコントロールパケットを送るときはいつも、それは制御タイマを設定します(同時にデータタイマをきれいにします、1つが設定されたなら)。
The control timer is cleared as follows: 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, and returns this number in every packet flowing
back to the receiver. The receiver is permitted to clear the
control timer of every packet with a sequence number equal to or
lower than the sequence number returned by the sender.
制御タイマは以下の通りきれいにされます: それぞれのコントロールメッセージはそれぞれのコントロールメッセージのための1時の始めと1の増加が送った一連番号を含んでいます。 発信しているNETBLTはそれが受けた他のすべての一連番号に対してあらゆる入って来るコントロールメッセージの一連番号をチェックします。 それは、他のすべての容認された一連番号が連続している最も高い一連番号を保存して、受信機に注いで戻りながら、あらゆるパケットでこの数を返します。一連番号が送付者で等しいか、または一連番号が戻ったより低い状態で受信機があらゆるパケットを制御タイマから取り除くことが許可されています。
Ideally, a NETBLT implementation should be able to cope with
out-of-sequence 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実装は順序が狂ってメッセージに対処できるべきです、すぐに後でそれらを処理するか、または処理さえするために恐らくそれらを集めて。 入って来るコントロールメッセージがメッセージ通番のグループの「穴」を「いっぱいにしている」なら、実装はこれを検出して、それに従って、外向的な系列値を調整できるくらい賢明でさえあるかもしれません。
When the control timer expires, the receiving NETBLT resends the
control message and resets the timer. After a predetermined
number of resends, the receiving NETBLT can assume that the
sending NETBLT has died, and can reset the connection.
制御タイマが期限が切れると、受信NETBLTはコントロールメッセージを再送して、タイマをリセットします。 設定回数の後、再送、受信NETBLTは、発信しているNETBLTが死んで、接続をリセットできると仮定できます。
The sending NETBLT, upon receiving a control message, should act
as quickly as possible on the packet; it either sets up a new
buffer (upon receipt of an OK packet for a previous buffer),
resends data (upon receipt of a RESEND packet), or sends data
コントロールメッセージを受け取るとき、発信しているNETBLTはできるだけはやくパケットに行動するはずです。 それは、新しいバッファをセットアップするか(前のバッファのためのOKパケットを受け取り次第)、データを再送するか(RESENDパケットを受け取り次第)、またはデータを送ります。
Clark & Lambert & Zhang [Page 8]
クラーク、ランバート、およびチャン[8ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
(upon receipt of a GO packet). If the sending NETBLT is not in a
position to send data, it sends a NULL-ACK packet, which contains
a
high-received-sequence-number as described above (this permits the
receiving NETBLT to clear the control timers of any packets which
are outstanding), and waits until it can send more data. In all
of these cases, the overhead for a response to the incoming
control message should be small; the total time for a response to
reach the receiving NETBLT should not be much more than the
network round-trip transit time, plus a variance factor.
(GOパケットを受け取り次第。) 発信しているNETBLTがデータを送る立場にないなら、それはNULL-ACKパケットを送ります。(それは、上(これは、受信NETBLTがどんな傑出しているパケットも制御タイマから取り除くことを許可する)で説明されるように高い容認された一連番号を含んでいて、より多くのデータを送ることができるまで、待ちます)。 これらの場合では、入って来るコントロールメッセージへの応答のためのオーバーヘッドは全部で、わずかであるべきです。 応答が受信NETBLTに達する総時間はネットワークの往復のトランジット時間、および変化の要素よりあまり多いはずがありません。
The 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 being transferred; a control
timer is active while it is between buffer transfers.
以下の通りタイマシステムをまとめることができます: 通常、受信NETBLTは2つのタイプのタイマ、制御タイマまたはデータタイマの働くひとりです。 バッファトランスミッションあたり1個のデータタイマとコントロールパケットあたり1個の制御タイマがあります。 データタイマはバッファを移している間、アクティブです。 バッファ転送の間には、それはありますが、制御タイマはアクティブです。
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 all its control timers 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 just hang waiting for control messages.
上のシステムはまだいくつかの問題を残しています。発信しているNETBLTが発信する準備ができていないなら、それは、犠牲者のどんな傑出している制御タイマもきれいにするために単一のNULL-ACKパケットを送ります。 この後、受信機は待っています。 発信しているNETBLTは死ぬことができました、そして、すべての制御タイマがきれいにされている状態で、受信機は掛かっているでしょう。 また、上のシステムは受信NETBLTにタイマを置くだけです。 発信しているNETBLTには、タイマが全くありません。 受信NETBLTが死ぬと、発信しているNETBLTは、コントロールメッセージを待ちながら、ただ掛かるでしょう。
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 at one end expires, it can assume the other
end has died and can close the connection.
上の2つの問題への解決は死亡タイマとkeepaliveパケットの両方の送受信NETBLTsの使用です。 接続が開かれるとすぐに、各端は死亡タイマを設定します。 パケットが受け取られているときはいつも、このタイマはリセットされます。 片端のNETBLTの死亡タイマが期限が切れると、それは、もう一方の端が死んで、接続を終えることができると仮定できます。
It is quite possible that the sending or receiving NETBLTs will
have to wait for long periods of time 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
is waiting for buffer space. 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
KEEPALIVEパケットが伝えられる頻度は以下の通り計算されます: 接続始動では、各NETBLTはaを選びます。
Clark & Lambert & Zhang [Page 9]
クラーク、ランバート、およびチャン[9ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
death-timeout 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.
死亡タイムアウトは、オープンかRESPONSEパケットのどちらかへのもう一方の端にそれを評価して、送ります。 もう一方の端は、死亡タイムアウト値を取って、パケットをKEEPALIVEに送る頻度を計算するのにそれを使用します。 KEEPALIVE頻度はもう一方の端の死亡タイマが期限が切れる前にいくつかのKEEPALIVEパケットが失われる場合があるほど高いはずです。
Both ends must have some way of estimating the values of the death
timers, the control timers, and the data timers. The timer values
obviously cannot be specified in a protocol document since they
are very machine- and network-load-dependent. Instead they must
be computed on a per-connection basis. The protocol has been
designed to make such determination easy.
両端に、死亡タイマ、制御タイマ、およびデータタイマの値を見積もる何らかの方法がなければなりません。 彼らがまさしくそのマシンとネットワーク負荷扶養家族であるので、プロトコルドキュメントで明らかにタイマ値を指定できません。 代わりに、1接続あたり1個のベースでそれらを計算しなければなりません。 プロトコルは、そのような決断を簡単にするように設計されています。
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を使用することで少なくとも一部基づくべきです。 ユーザアプリケーションには、タイムアウトが人間を長い期間の間、死亡タイムアウトが起こるのを待たせるのを避けるために評価するより小さい死があるべきです。 マシンアプリケーションは、より長いタイムアウト値を持つことができます。
The control timer must be more carefully estimated. It can have
as its initial value an arbitrary number; this number can be used
to send the first control packet. Subsequent control packets can
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 the corresponding sequence number)
plus a variance factor. The timer value should be continually
updated, based on a smoothed average of collected round-trip
transit times.
より慎重に制御タイマを見積もらなければなりません。 それは初期の値として特殊活字の数字を持つことができます。 最初のコントロールパケットを送るのにこの数を使用できます。 その後のコントロールパケットは往復のトランジット時間(すなわち、コントロールパケットを送って、対応する一連番号の承認を受けることの間の時間)と変化の要素をネットワークに基礎づけたはずですそれらのタイマが、評価する。 集まっている往復のトランジット時間の平坦な平均に基づいて絶えずタイマ値をアップデートするべきです。
The data timer is dependent not on the network round-trip transit
time, but on the amount of time required to transfer a buffer of
data. The time value can be computed from the burst rate and the
number of bursts per buffer, plus a variance value <1>. During the
RESENDing phase, the data timer value should be set according to
the number of missing packets.
データタイマはネットワークの往復のトランジット時間に依存するのではなく、データに関するバッファを移すのに必要である時間に依存しています。 時間的価値は計算されて、炸裂が評価するということであるかもしれなく、1バッファあたりの炸裂の数、および変化の値の<は1>です。 RESENDing段階の間、なくなったパケットの数に従って、データタイマ価値は設定されるべきです。
The timers have been designed to permit reasonable estimation. In
particular, in other protocols, determination of round-trip delay
has been a problem since the action performed by the other end on
receipt of a particular packet can vary greatly depending on the
packet type. In NETBLT, the action taken by the sender on receipt
of a control message is by and large the same in all cases, making
the round-trip delay relatively independent of the client.
タイマは、合理的な見積りを可能にするように設計されています。 パケットタイプに大いに頼っていて、特定のパケットを受け取り次第もう一方の端までに実行された動作が異なることができるので、他のプロトコルでは、往復の遅れの決断は特に、問題です。 NETBLTでは、コントロールメッセージを受け取り次第送付者によって取られた行動は概して、往復を作って、すべてがケースに入れる同じコネがクライアントから比較的独立していた状態で延着するということです。
Clark & Lambert & Zhang [Page 10]
クラーク、ランバート、およびチャン[10ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
Timer value estimation is extremely important, especially in a
high-performance protocol like NETBLT. If the estimates are too
low, the protocol makes many unneeded retransmissions, degrading
performance. A short control timer value causes the sending
NETBLT to receive duplicate control messages (which it can reject,
but which takes time). A short data timer value causes the
receiving NETBLT to send unnecessary RESEND packets. This causes
considerably greater performance degradation since the sending
NETBLT does not merely throw away a duplicate packet, but instead
has to send a number of DATA packets. Because data timers are set
on each buffer transfer instead of on each DATA packet transfer,
we afford to use a small variance value without worrying about
performance degradation.
タイマ値の見積りは特にNETBLTのような高性能プロトコルで非常に重要です。 見積りが低過ぎるなら、性能を下げて、プロトコルは多くの不要な「再-トランスミッション」を作ります。 短いコントロールタイマ価値で、発信しているNETBLTは写しコントロールメッセージを受け取ります(拒絶できますが、時間がかかります)。 短いデータタイマ価値で、受信NETBLTは不要なRESENDパケットを送ります。 これは、発信しているNETBLTが単に写しパケットを捨てないのでかなり大きい性能に退行を引き起こしますが、代わりに多くのDATAにパケットを送らなければなりません。 データタイマがそれぞれのDATAパケット転送の代わりにそれぞれのバッファ転送に設定されるので、私たちは、性能退行を心配しないで小さい変化の値を使用するのを提供します。
5.3. Closing the Connection
5.3. 接続を終えます。
There are three ways to close a connection: a connection close, a
"quit", or an "abort".
接続を終える3つの方法があります: 接続閉鎖、「辞任」、または「アボート。」
The connection close occurs after a successful data transfer.
When the sending NETBLT has received an OK packet for the last
buffer in the transfer, it sends a DONE packet <2>. On receipt of
the DONE packet, the receiving NETBLT can close its half of the
connection. The sending NETBLT dallies for a predetermined amount
of time after sending the DONE packet. This allows for the
possibility of the DONE packet's having been lost. If the DONE
packet was lost, the receiving NETBLT will continue to send the
final OK packet, which will cause the sending end to resend the
DONE packet. After the dally period expires, the sending NETBLT
closes its half of the connection.
接続閉鎖はうまくいっているデータ転送の後に起こります。 発信しているNETBLTが転送における最後のバッファのためにOKパケットを受けたとき、それはDONEパケット<2>を送ります。 DONEパケットを受け取り次第、受信NETBLTは半分の接続を終えることができます。 DONEパケットを送った後に、発信しているNETBLTは予定された時間、ふざけます。 失われて、これはパケットのDONEものの可能性を考慮します。 DONEパケットが失われたなら、受信NETBLTは、最終的なOKパケットを送り続けるでしょう。(送信側はパケットでDONEパケットを再送するでしょう)。 ふざけてください。期間は期限が切れて、送付NETBLTは半分の接続を終えます。
During the 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 to immediately notify its
client and transmit a QUITACK packet. The QUIT sender must time
out and retransmit until a QUITACK has been received or a
predetermined number of resends have taken place. The sender of
the QUITACK dallies in the manner described above.
転送の間、それが、もう片方のクライアントが誤動作していると思うなら、1人のクライアントがQUITパケットをもう片方に送るかもしれません。 QUITがクライアントレベルで起こるので、QUITトランスミッションはバッファトランスミッションの間に起こることができるだけです。 QUITパケットを受けるNETBLTはすぐに、クライアントに通知して、QUITACKパケットを伝える以外の行動を全く取ることができません。 QUIT送付者必須タイムアウト、QUITACKが受け取られていて設定回数になるまで再送してください、再送、行われました。 QUITACKの送付者は上で説明された方法でふざけます。
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. Since the ABORT implies
that the NETBLT layer is malfunctioning, no transmit reliability
is expected, and the sender can immediately close it connection.
NETBLT層が、それかその正反対が誤動作していると思うとき、ABORTは行われます。 ABORTがNETBLT層で起こるので、いつでも、それを送ることができます。 ABORTが、NETBLT層がいいえが誤動作、伝わるということであることを含意して、信頼性は予想されます、そして、送付者はすぐに、それを閉じることができます。接続。
Clark & Lambert & Zhang [Page 11]
クラーク、ランバート、およびチャン[11ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
6. MULTIPLE BUFFERING
6. 複数のバッファリング
In order to increase performance, NETBLT has been designed in a manner that encourages a multiple buffering implementation. Multiple buffering is a technique in which the sender and receiver allocate and transmit buffers in a manner that allows error recovery of previous buffers to be concurrent with transmission of current buffer.
性能を増強するために、NETBLTは実装をバッファリングする倍数を奨励する方法で設計されています。 複数のバッファリングが送付者と受信機が前のバッファのエラー回復が現在のバッファの伝達で同時発生であることを許容する方法によるバッファを割り当てて、伝えるテクニックです。
During the connection setup phase, one of the negotiated parameters is the number of concurrent buffers permitted during the transfer. The simplest transfer allows for a maximum of one buffer to be transmitted at a time; this is effectively a lock-step protocol and causes time to be wasted while the sending NETBLT receives permission to send a new buffer. If there are more than one buffer available, transfer of the next buffer may start right after the current buffer finishes. For example, assume buffer A and B are allowed to transfer concurrently, with A preceding B. As soon as A finishes transferring its data and is waiting for either an OK or a RESEND message, B can start sending immediately, keeping data flowing at a stable rate. If A receives an OK, it is done; if it receives a RESEND, the missing packets specified in the RESEND message are retransmitted. All packets flow out through a priority pipe, with the priority equal to the buffer number, and with the transfer rate specified by the burst size and burst rate. Since buffer numbers increase monotonically, packets from an earlier buffer in the pipe will always precede those of the later ones. One necessary change to the timing algorithm is that when the receiving NETBLT set data timer for a new buffer, the timer value should also take into consideration of the transfer time for all missing packets from the previous buffers.
接続設定段階の間、交渉されたパラメタの1つは転送の間に受入れられた同時発生のバッファの数です。 最も簡単な転送は、最大1つのバッファが一度に伝えられるのを許容します。 これは、事実上堅苦しいプロトコルであり、発信しているNETBLTは新しいバッファを送る許可を受けますが、浪費されるべき時間を引き起こします。 以上が利用可能な1つのバッファよりあれば、現在のバッファが終わったまさしく後に次のバッファの転送は始まるかもしれません。 例えば、AとBが同時に移すことができるバッファを仮定してください、Aと共に、すぐAとしてB.Asに先行するのは、データを移し終えて、OKの待つことですまたはRESENDメッセージ、Bは、すぐに発信し始めることができます、データを安定した速度で流れさせ続けて。 AがOKを受けるなら、それをします。 RESENDを受けるなら、RESENDメッセージで指定されたなくなったパケットは再送されます。 バッファ数と等しい優先権、および転送レートが放出量と炸裂率によって指定されている状態で、すべてのパケットが優先権パイプを通した外を流れます。 バッファ数が単調に増加するので、パイプの以前のバッファからのパケットはいつも後のもののものに先行するでしょう。 タイミングアルゴリズムへの1回の必要な変化はまた、受信NETBLTが新しいバッファにデータタイマを設定すると、タイマ値が前のバッファからすべてのなくなったパケットのための転送時間の考慮を連れていくべきであるということです。
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つの有限状態機械のグループです。 転送プロセスはトランスミッションが完成した全体までバッファを様々な州を通って動かすのから成ります。
The state sequence of a send-receive buffer pair is as follows: the sending and receiving buffers are created independently. The receiving NETBLT sends a GO message, putting its buffer in a "receiving" state, and sets its control timer; the sending NETBLT receives the GO message, putting its buffer into a "sending" state. The sending NETBLT sends data until the buffer has been transmitted. If the receiving NETBLT's data timer goes off before it received the last (LDATA) packet, or it receives the LDATA packet in the buffer
受信バッファを発信させている組のステート・シーケンスは以下の通りです: 送受信バッファは独自に作成されます。 受信NETBLTは「受信」状態にバッファを置いて、GOメッセージを送って、制御タイマを設定します。 「送付」状態にバッファを入れて、発信しているNETBLTはGOメッセージを受け取ります。 バッファが伝えられるまで、発信しているNETBLTはデータを送ります。 最後の(LDATA)パケットを受ける前に受信NETBLTのデータタイマが発射されるか、またはバッファでLDATAパケットを受けるなら
Clark & Lambert & Zhang [Page 12]
クラーク、ランバート、およびチャン[12ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
and packets are missing, it sends a RESEND packet and moves the buffer into a "resending" state. Once all DATA packets in the buffer and the LDATA packet have been received, the receiving NETBLT enters its buffer into a "received" state and sends an OK packet. The sending NETBLT receives the OK packet and puts its buffer into a "sent" state.
そして、パケットがなくなって、それは、「再送」状態にRESENDパケットを送って、バッファを動かします。 いったんバッファのすべてのDATAパケットとLDATAパケットを受け取ると、受信NETBLTは「受け取られていている」状態にバッファを入力して、OKパケットを送ります。 発信しているNETBLTはOKパケットを受けて、「送られた」状態にバッファを入れます。
7. PROTOCOL LAYERING STRUCTURE
7. プロトコルレイヤリング構造
NETBLT is implemented directly on top of the Internet Protocol (IP). It has been assigned a temporary protocol number of 255. This number will change as soon as the final protocol specification has been determined.
NETBLTは直接インターネットプロトコル(IP)の上で実装されます。 一時的なプロトコル番号の255をそれに割り当ててあります。 最終的なプロトコル仕様が決定しているとすぐに、この数は変化するでしょう。
8. PACKET FORMATS
8. パケット・フォーマット
NETBLT packets are divided into three categories, each of which share a common packet header. First, there are those packets that travel only from sender to receiver; these contain the control message sequence numbers which the receiver uses for 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 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)の特殊活字の数字を含むことができます、それぞれそれ自身の一連番号で。 最終的に、信頼性を保障する特別な方法を持っているか、または確かに伝えられないそれらのパケットがあります。 これらは、QUITと、QUITACKと、DONEと、KEEPALIVEと、ABORTパケットです。 これらでは、すべてがともにNETBLTsを送って、受けることによってパケットを送ることができるDONEを取っておきます。
Packet type numbers:
パケット形式数:
OPEN: 0
RESPONSE: 1
KEEPALIVE: 2
DONE: 3
QUIT: 4
QUITACK: 5
ABORT: 6
DATA: 7
LDATA: 8
NULL-ACK: 9
CONTROL: 10
以下を開いてください。 0応答: 1KEEPALIVE: 2 される: 3 やめます: 4QUITACK: 5は中止になります: 6つのデータ: 7LDATA: 8 ヌルACK: 9 コントロール: 10
Clark & Lambert & Zhang [Page 13]
クラーク、ランバート、およびチャン[13ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
Standard header:
標準のヘッダー:
local port: 2 bytes
foreign port: 2 bytes
checksum: 2 bytes
version number: 1 byte
packet type: 1 byte
packet length: 2 bytes
地方のポート: 2バイトの外国ポート: 2バイトのチェックサム: 2バイトのバージョン番号: 1バイトのパケットタイプ: 1バイトのパケット長: 2バイト
OPEN and RESPONSE packets:
オープンとRESPONSEパケット:
connection unique ID: 4 bytes
standard buffer size: 4 bytes
transfer size: 4 bytes
DATA packet data segment size: 2 bytes
burst size: 2 bytes
burst rate: 2 bytes
death timeout value in seconds: 2 bytes
transfer mode (1 = SEND, 0 = RECEIVE): 1 byte
maximum number of concurrent buffers: 1 byte
checksum entire DATA packet / checksum
DATA packet data only (1/0): 1 byte
client-specific data: arbitrary
接続のユニークなID: 4バイトの標準のバッファサイズ: 4バイトはサイズを移します: 4バイトのDATAパケットデータ・セグメントサイズ: 2バイトはサイズを押し破きました: 2バイトはレートを押し破きました: 秒の2バイトの死亡タイムアウト価値: 2バイトはモードを移します(1=SEND、0はRECEIVEと等しいです): 1バイトの最大数の同時発生のバッファ: 1バイトのチェックサムの全体のDATAパケット/チェックサムDATAパケットデータだけ、(1/0): 1バイトのクライアント特有のデータ: 任意
DONE, QUITACK, KEEPALIVE:
QUITACK、KEEPALIVE、した、:
standard header only
標準のヘッダー専用
ABORT, QUIT:
中止になってください、そして、やめてください:
reason: arbitrary bytes
理由: 任意のバイト
CONTROL packet format:
CONTROLパケット・フォーマット:
CONTROL packets consist of a standard NETBLT header of type
CONTROL, followed by an arbitrary number of control messages with
the following formats:
CONTROLパケットは以下の形式があるコントロールメッセージの特殊活字の数字があとに続いたタイプCONTROLの標準のNETBLTヘッダーから成ります:
Control message numbers:
メッセージ番号を制御してください:
GO: 0
OK: 1
RESEND: 2
行きます: 0 OK: 1 再送します: 2
Clark & Lambert & Zhang [Page 14]
クラーク、ランバート、およびチャン[14ページ]
RFC 969 December 1985 NETBLT: A Bulk Data Transfer Protocol
RFC969 1985年12月のNETBLT: バルク・データ転送プロトコル
OK message:
メッセージを承認してください:
message type (OK): 1 byte
buffer number: 4 bytes
sequence number: 2 bytes
new burst size: 2 bytes
new burst interval: 2 bytes
メッセージタイプ(OK): 1バイトのバッファ数: 4バイトの一連番号: 2バイトの新しい放出量: 2バイトの新しい炸裂間隔: 2バイト
GO message:
GOメッセージ:
message type (GO): 1 byte
buffer number: 4 bytes
sequence number: 2 bytes
メッセージタイプ(GO): 1バイトのバッファ数: 4バイトの一連番号: 2バイト
RESEND message:
RESENDメッセージ:
message type (RESEND): 1 byte
buffer number: 4 bytes
sequence number: 2 bytes
number of missing packets: 2 bytes
packet numbers...: n * 2 bytes
メッセージタイプ(RESEND): 1バイトのバッファ数: 4バイトの一連番号: なくなったパケットの2バイトの数: 2バイトのパケット番号…: n*2バイト
DATA, LDATA packet formats:
DATA、LDATAパケット・フォーマット:
buffer number: 4 bytes
highest consecutive sequence number received: 2 bytes
packet number within buffer: 2 bytes
data: arbitrary bytes
バッファ数: 最も高い連続した一連番号が受けた4バイト: 2バイトのパケット番号は中で以下をバッファリングします。 2バイトのデータ: 任意のバイト
NULL-ACK packet format:
NULL-ACKパケット・フォーマット:
highest consecutive sequence number received: 2 bytes
acknowledged new burst size: 2 bytes
acknowledged new burst interval: 2 bytes
最も高い連続した一連番号は受けました: 新しい状態で承認された2バイトはサイズを押し破きました: 新しい状態で承認された2バイトは間隔を押し破きました: 2バイト
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 can be
verified in further testing.
<、バッファサイズであるときに、1>が大きい、多くのパケットの周遊旅行遅れにおける変化は互いを相殺するかもしれません。 これは、変化の値がそれほど大きい必要はないことを意味します。 追加検査でこの期待について確かめることができます。
<2> Since the receiving end may not know the transfer size in
advance, it is possible that it may have allocated buffer space
and sent GO messages for buffers beyond the actual last buffer
sent by the sending end. Care must be taken on the sending
end's part to ignore these extra GO messages.
犠牲者があらかじめ転送サイズを知らないかもしれなくて以来の<2>、送信側までに送られた最後の実際のバッファを超えたバッファのためにバッファ領域を割り当てて、メッセージをGOに送ったのは、可能です。 これらの付加的なGOメッセージを無視するために送信側の部分における注意しなければなりません。
Clark & Lambert & Zhang [Page 15]
クラーク、ランバート、およびチャン[15ページ]
一覧
スポンサーリンク
