RFC1986 日本語訳
1986 Experiments with a Simple File Transfer Protocol for Radio Linksusing Enhanced Trivial File Transfer Protocol (ETFTP). W. Polites, W.Wollman, D. Woo, R. Langan. August 1996. (Format: TXT=49772 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Polites
Request for Comments: 1986 W. Wollman
Category: Experimental D. Woo
The MITRE Corporation
R. Langan
U.S. ARMY CECOM
August 1996
Politesがコメントのために要求するワーキンググループW.をネットワークでつないでください: 1986年のW.ウォルマンカテゴリ: 実験的なD.はCECOM1996年8月に斜め継ぎ社のR.ランガン米国軍隊に言い寄ります。
Experiments with a Simple File Transfer Protocol for Radio Links
using Enhanced Trivial File Transfer Protocol (ETFTP)
ラジオリンクへの簡単なファイル転送プロトコルが高められたトリビアル・ファイル転送プロトコルを使用している実験(ETFTP)
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
1. INTRODUCTION SECTION
1. 序論部
This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. It uses the User Datagram Protocol (UDP), RFC 768 [2], as its transport layer. The two protocols are layered to create the ETFTP client server application. The ETFTP program is named after Trivial File Transfer Protocol (TFTP), RFC 1350 [3], because the source code from TFTP is used as the building blocks for the ETFTP program. This implementation also builds on but differs from the work done by the National Imagery Transmission Format Standard [4].
このドキュメントはEnhancedトリビアル・ファイル転送プロトコル(ETFTP)の記述です。 このプロトコルはNETwork BLock Transferプロトコル(NETBLT)の実験的な実装です、RFC998[1]、ファイル転送アプリケーション・プログラムとして。 それはトランスポート層としてユーザー・データグラム・プロトコル(UDP)、RFC768[2]を使用します。 2つのプロトコルが、ETFTPクライアントサーバ・アプリケーションを作成するために層にされます。 ETFTPプログラムはトリビアル・ファイル転送プロトコル(TFTP)にちなんで名付けられます、RFC1350[3]、ETFTPのためのブロックがプログラムを作るときTFTPからのソースコードが使用されているので。 また、建てますが、National Imagery Transmission Format Standard[4]によって行われた仕事とこの実装を異なっています。
This document is published for discussion and comment on improving the throughput performance of data transfer utilities over Internet Protocol (IP) compliant, half duplex, radio networks.
このドキュメントはインターネットの上でプロトコル(IP)対応することでデータ転送ユーティリティのスループット性能を向上させる議論とコメントのために発表されます、半二重、ラジオ放送網。
There are many file transfer programs available for computer networks. Many of these programs are designed for operations through high-speed, low bit error rate (BER) cabled networks. In tactical radio networks, traditional file transfer protocols, such as File Transfer Protocol (FTP) and TFTP, do not always perform well. This is primarily because tactical half duplex radio networks typically provide slow-speed, long delay, and high BER communication links. ETFTP is designed to allow a user to control transmission parameters to optimize file transfer rates through half-duplex radio links.
コンピュータネットワークに利用可能な多くのファイル転送プログラムがあります。 これらのプログラムの多くが操作のためにネットワークに電報を打たれた高速で、低ビット誤り率(BER)を通して設計されています。 戦術のラジオ放送網では、File Transferプロトコル(FTP)やTFTPなどの伝統的なファイル転送プロトコルはいつもよく振る舞うというわけではありません。 これは主として戦術の半二重ラジオ放送網が遅い速度、長時間の遅延、および高いBER通信リンクを通常提供するからです。 ETFTPは、ユーザが半二重ラジオリンクを通してファイル転送率を最適化するためにトランスミッションパラメタを制御するのを許容するように設計されています。
Polites, Wollman & Woo Experimental [Page 1] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[1ページ]RFC1986に言い寄ってください。
The tactical radio network used to test this application was developed by the Survivable Adaptive Systems (SAS) Advanced Technology Demonstration (ATD). Part of the SAS ATD program was to address the problems associated with extending IP networks across tactical radios. Several tactical radios, such as, SINgle Channel Ground and Airborne Radio Systems (SINCGARS), Enhanced Position Location Reporting Systems (EPLRS), Motorola LST-5C, and High Frequency (HF) radios have been interfaced to the system. This document will discuss results obtained from using ETFTP across a point-to-point LST-5C tactical SATellite COMmunications (SATCOM) link. The network includes a 25 Mhz 486 Personal Computer (PC) called the Army Lightweight Computer Unit (LCU), Cisco 2500 routers, Gracilis PackeTen Network switches, Motorola Sunburst Cryptographic processors, a prototype forward error correction (FEC) device, and Motorola LST-5C tactical Ultra High Frequency (UHF) satellite communications (SATC! OM) radio. Table 1, "Network Trans fer Rates," describes the equipment network connections and the bandwidth of the physical media interconnecting the devices.
Survivable Adaptive Systemsの(SAS)高度なTechnology Demonstration(ATD)はこのアプリケーションを検査するのに使用される戦術のラジオ放送網を発展させました。 SAS ATDプログラムの一部は戦術のラジオの向こう側にIPネットワークを広げると関連しているその問題を訴えることでした。 数個の戦術のラジオ、あれほどです、(HF)が無線連絡するモトローラのSINgle Channel Ground、Airborne Radio Systems(SINCGARS)、Enhanced Position Location Reporting Systems(EPLRS)、LST-5C、およびHigh Frequencyはシステムに接続されました。 このドキュメントは二地点間戦術のLST-5CのSATellite COMmunications(SATCOM)リンクの向こう側にETFTPを使用するのから得られた結果について議論するでしょう。 ネットワークは陸軍ライト級コンピュータUnit(LCU)と呼ばれる25Mhz486パーソナルコンピュータ(PC)、シスコ2500ルータ、Gracilis PackeTen Networkスイッチ、モトローラSunburst Cryptographicプロセッサ、プロトタイプ前進型誤信号訂正(FEC)デバイス、およびモトローラ戦術のLST-5Cの極超短波(UHF)衛星通信を含んでいます。(SATC! オミ) ラジオ。 「ネットワーク移-ferレート」というテーブル1はデバイスとインタコネクトする物理的なメディアの設備ネットワーク接続と帯域幅について説明します。
Table 1: Network Transfer Rates
テーブル1: ネットワーク転送レート
+-------------------------------+-------------------------------+ | Equipment | Rate (bits per second) | +-------------------------------+-------------------------------+ | Host Computer (486 PC) | 10,000,000 Ethernet | +-------------------------------+-------------------------------+ | Cisco Router | 10,000,000 Ethernet to | | | 19,200 Serial Line Internet | | | Protocol (SLIP) | +-------------------------------+-------------------------------+ | Gracilis PackeTen | 19,200 SLIP to | | | 16,000 Amateur Radio (AX.25) | +-------------------------------+-------------------------------+ | FEC | half rate or quarter rate | +-------------------------------+-------------------------------+ | Sunburst Crypto | 16,000 | +-------------------------------+-------------------------------+ | LST-5C Radio | 16,000 | +-------------------------------+-------------------------------+
+-------------------------------+-------------------------------+ | 設備| レート(bps)| +-------------------------------+-------------------------------+ | ホストコンピュータ(486PC)| 1000万のイーサネット| +-------------------------------+-------------------------------+ | コクチマスルータ| 1000万のイーサネット| | | 1万9200 シリアル・ラインインターネット| | | プロトコル(メモ用紙)| +-------------------------------+-------------------------------+ | Gracilis PackeTen| 1万9200は滑ります。| | | 1万6000 アマチュア無線(斧.25)| +-------------------------------+-------------------------------+ | FEC| 半分レートか4分の1レート| +-------------------------------+-------------------------------+ | 強烈な日光暗号| 16,000 | +-------------------------------+-------------------------------+ | LST-5Cのラジオ| 16,000 | +-------------------------------+-------------------------------+
During 1993, the MITRE team collected data for network configurations that were stationary and on-the-move. This network configuration did not include any Forward Error Correction (FEC) at the link layer. Several commercially available implementations of FTP were used to transfer files through a 16 kbps satellite link. FTP relies upon the Transmission Control Protocol (TCP) for reliable communications. For a variety of file sizes, throughput measurements ranged between 80 and 400 bps. At times, TCP connections could be opened, however, data
1993の間、MITREチームは静止して移動中であるネットワーク・コンフィギュレーションのためのデータを集めました。 このネットワーク・コンフィギュレーションはリンクレイヤの少しのForward Error Correction(FEC)も含んでいませんでした。 FTPのいくつかの商業的に利用可能な実装が、16キロビット毎秒衛星中継を通してファイルを移すのに使用されました。 FTPは信頼できるコミュニケーションのために通信制御プロトコル(TCP)を当てにします。 さまざまなファイルサイズのために、スループット測定値は80と400ビーピーエスの間で及びました。 しかしながら、時にはTCP接続を開くことができた、データ
Polites, Wollman & Woo Experimental [Page 2] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[2ページ]RFC1986に言い寄ってください。
transfers would be unsuccessful. This was most likely due to the smaller TCP connection synchronization packets, as compared to the TCP data packets. Because of the high bit error rate of the link, the smaller packets were much more likely to be received without error. In most cases, satellite channel utilization was less than 20 percent. Very often a file transfer would fail because FTP implementations would curtail the transfer due t! o the poor conditions of the commu nication link.
転送は失敗しているでしょう。 TCPデータ・パケットと比べて、これはたぶんより小さいTCP接続同期パケットのためでした。 リンクの高いビット誤り率のために、より小さいパケットは誤りなしではるかに受け取られそうでした。 多くの場合、衛星チャンネル利用は20パーセント未満でした。 FTP実装は転送支払われるべきものtを縮小するでしょう、したがって、頻繁に、ファイル転送が失敗します!○ commu nicationに関する劣悪な条件はリンクされます。
The current focus is to increase the throughput and channel utilization over a point to point, half duplex link. Follow on experiments will evaluate ETFTP's ability to work with multiple hosts in a multicast scenario. Evaluation of the data collected helped to determine that several factors limited data throughput. A brief description of those limiting factors, as well as, solutions that can reduce these networking limitations is provided below.
現在の焦点はポイント・ツー・ポイント、半二重リンクの上にスループットとチャンネル利用を増強することになっています。 実験の尾行はマルチキャストシナリオの複数のホストと共に働くETFTPの性能を評価するでしょう。 集められたデータの評価は、数個が限られたデータスループットを因数分解することを決定するのを助けました。 それらの簡単な説明が要素を制限して、良くて、これらのネットワーク制限を抑えることができる解決法を以下に提供します。
Link Quality
リンク品質
The channel quality of a typical narrow-band UHF satellite link does not sufficiently support data communications without the addition of a forward error correction (FEC) capability. From the data collected, it was determined that the UHF satellite link supports, on average, a 10e-3 bit error rate.
典型的な狭周波数帯UHF衛星中継のチャンネル品質は、前進型誤信号訂正(FEC)能力の追加なしでデータがコミュニケーションであると十分サポートしません。 集められたデータから、UHF衛星中継が10e-3ビット誤り率を平均的にサポートするのは、決定していました。
Solution: A narrow-band UHF satellite radio FEC prototype was developed that improves data reliability, without excessively increasing synchronization requirements. The prototype FEC increased synchronization requirements by less than 50 milliseconds (ms). The FEC implementation will improve an average 10e-3 BER channel to an average 10e-5 BER channel.
ソリューション: 過度に増加する同期要件なしでデータの信頼性を改良する狭周波数帯UHF衛星ラジオFECプロトタイプは発生しました。 プロトタイプFECは同期要件を50ミリセカンド未満(ms)と同じくらい増強しました。 FEC実装は普通の10e-5 BERチャンネルの普通の10e-3 BERチャンネルを改良するでしょう。
Delays
遅れ
Including satellite propagation delays, the tactical satellite radios require approximately 1.25 seconds for radio synchronization prior to transmitting any data across the communication channel. Therefore, limiting the number of channel accesses required will permit data throughput to increase. This can be achieved by minimizing the number of acknowledgments required during the file transfer. FTP generates many acknowledgments which decreases throughput by increasing the number of satellite channel accesses required.
衛星伝播遅延、通信チャネルの向こう側にどんなデータも送るラジオ同期のためのおよそ1.25秒前のラジオが必要とする戦術の衛星を含んでいます。 したがって、チャンネルアクセスの数が必要とした制限は、データスループットが増加することを許可するでしょう。 ファイル転送の間必要である承認の数を最小にすることによって、これを達成できます。 FTPは、多くの承認が衛星チャンネルアクセスの数を増強するのによるスループットが必要としたどの減少であるかと生成します。
To clarify, when a FTP connection request is generated, it is sent via Ethernet to the router and then forwarded to the radio network controller (RNC). The elapsed time is less than 30 ms. The RNC keys the crypto unit and 950 ms later modem/crypto synchronization occurs. After synchronization is achieved, the FTP connection request is
FTP接続要求が発生しているとき、はっきりさせるために、それをイーサネットでルータに送って、次に、ラジオネットワーク制御装置(RNC)に送ります。 経過時間は30未満原稿です。RNCは暗号ユニットを合わせます、そして、950のmsの後のモデム/暗号同期は起こります。 同期が達成された後に、FTP接続要求は達成されます。
Polites, Wollman & Woo Experimental [Page 3] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[3ページ]RFC1986に言い寄ってください。
transmitted. The transmitting terminal then drops the channel and the modem/crypto synchronization is lost. Assuming that the request was received successfully, the receiving host processes the request and sends an acknowledgment. Again the modem/crypto have to synchronize prior to transmitting the acknowledgment. Propagation delays over a UHF satellite also adds roughly 500 ms to the total round trip delay.
伝えられる。 次に、伝える端末はチャンネルを下げます、そして、モデム/暗号同期は無くなっています。 要求が首尾よく受け取られたと仮定して、受信ホストは、要求を処理して、承認を送ります。 一方、承認を伝える前に、モデム/暗号は同期しなければなりません。 また、UHF衛星の上の伝播遅延は旅行遅れの周りでおよそ500msを合計に加えます。
Solution: When compared to FTP, NETBLT significantly reduces the number of acknowledgments required to complete a file transfer. Therefore, leveraging the features available within an implementation of NETBLT will significantly improve throughput across the narrow- band UHF satellite communication link.
ソリューション: FTPと比べると、NETBLTはファイル転送を終了するのに必要である承認の数をかなり減少させます。 したがって、NETBLTの実装の中で利用可能な特徴を利用すると、スループットは細長いバンドUHF衛星通信リンクの向こう側にかなり改良されるでしょう。
To reduce the number of channel accesses required, a number of AX.25 parameters were modified. These included the value of p for use within the p-persistence link layer protocol, the slot time, the transmit tail time, and the transmit delay time. The p-persistence is a random number threshold between 0 and 255. The slot time is the time to wait prior to attempting to access the channel. The transmit tail increases the amount of time the radio carrier is held on, prior to dropping the channel. Transmit delay is normally equal to the value of the radio synchronization time. By adjusting these parameters to adapt to the tactical satellite environment, improved communication performance can be achieved.
減少するのに、チャンネルアクセスの数が必要であり、多くのAX.25パラメタが変更されました。 そして、これらはp-固執リンクレイヤプロトコルの中に使用のためのpの値を含んでいました、スロット時間、テール時間を伝えてください、遅延時間を伝えてください。 p-固執は0と255の間の乱数敷居です。 スロット時間はチャンネルにアクセスするのを試みる前に待つ時間です。 チャンネルを下げる前にラジオキャリヤーがオンに持たれている時間にテール増加を伝えてください。 伝わってください。通常、遅れはラジオ同期時間の値と等しいです。 戦術の衛星環境に順応するようにこれらのパラメタを調整することによって、向上したコミュニケーション性能を達成できます。
First, in ETFTP, several packets within a buffer are transmitted within one burst. If the buffer is partitioned into ten packets, each of 1024 bytes, then 10,240 bytes of data is transmitted with each channel access. It is possible to configure ETFTP's burstsize to equal the number of packets per buffer. Second, the transmit tail time was increased to hold the key down on the transmitter long enough to insure all of the packets within the buffer are sent in a single channel access. These two features, together, allow the system to transmit an entire file (example, 100,000 bytes) with only a single channel access by adjusting buffer size. Thirdly, the ETFTP protocol only acknowledges each buffer, not each packet. Thus, a single acknowledgment is sent from the receiving terminal containing a request for the missing packets within each buffer, reducing the number of acknowledgment packets sent. Which in turn, reduced the number of times the channel has to be turned around.
まず最初に、バッファの中のいくつかのパケットが1回の炸裂の中でETFTPでは、伝えられます。 バッファが10のパケットに仕切られるなら、それぞれ1024バイト、1万240バイトのデータはそれぞれのチャンネルアクセサリーで送られます。 ETFTPのものが1バッファあたりのパケットの数と等しいようにburstsizeするのを構成するのは可能です。 2番目に、伝える、テール時間は、バッファの中のパケットのすべてが単一のチャンネルアクセサリーで送られるのを保障できるくらい長い送信機の上に鍵を握るために増強されました。 これらの2つの特徴で、システムは、ただ一つのチャンネルアクセスだけでバッファサイズを調整することによって、ファイル全体(例、10万バイト)を一緒に、送ることができます。 三番目に、ETFTPプロトコルは各パケットではなく、各バッファを承認するだけです。 したがって、各バッファの中になくなったパケットを求める要求を含む受信端末からただ一つの承認を送ります、パケットが送った承認の数を減少させて。 どれ、順番に、減少して、チャンネルが回数でなければならないことは振り向いたか。
To reduce channel access time, p-persistence was set to the maximum value and slot time to a minimum value. These settings support operations for a point-to-point communication link between two users. This value of p would not be used if more users were sharing the satellite channel.
チャンネルアクセスタイムを減少させるために、p-固執は最小値への最大値とスロット時間に設定されました。 これらの設定は2人のユーザの間の二地点間通信リンクのための操作をサポートします。 より多くのユーザが衛星チャンネルを共有しているなら、pのこの値は使用されないでしょうに。
Polites, Wollman & Woo Experimental [Page 4] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[4ページ]RFC1986に言い寄ってください。
Backoffs
Backoffs
TCP's slow start and backoff algorithms implemented in most TCP packages assume that packet loss is due to network congestion. When operating across a tactical half duplex communication channel dedicated to two users, packet loss is primarily due to poor channel quality, not network congestion. A linear backoff at the transport layer is recommended. In a tactical radio network there are numerous cases where a single host is connected to multiple radios. In a tactical radio network, layer two will handle channel access. Channel access will be adjusted through parameters like p-persistence and slot time. The aggregate effect of the exponential backoff from the transport layer added to the random backoff of the data link layer, will in most cases, cause the radio network to miss many network access opportunities. A linear backoff will reduce the number missed data link network access opportunities
ほとんどのTCPパッケージの中に実装されたTCPの遅れた出発とbackoffアルゴリズムは、パケット損失がネットワークの混雑のためであると仮定します。 2人のユーザに専念した戦術の半二重通信チャンネルの向こう側に作動するとき、パケット損失はネットワークの混雑ではなく、主として劣ったチャンネル品質のためです。 トランスポート層の直線的なbackoffはお勧めです。 戦術のラジオ放送網には、多数のケースが独身のホストが複数のラジオに接続されるところにあります。 戦術のラジオ放送網では、層twoはチャンネルアクセサリーを扱うでしょう。 チャンネルアクセスはp-固執とスロット時間のようなパラメタを通して調整されるでしょう。 データ・リンク層の無作為のbackoffに加えられたトランスポート層からの指数のbackoffの集合効果、多くの場合、ラジオが多くのネットワークアクセスの機会を逃すようにネットワークでつなぐ原因。 直線的なbackoffは数の逃されたデータ・リンクネットワークアクセスの機会を減少させるでしょう。
Solution: Tunable parameters and timers have been modified to resemble those suggested by NETBLT.
ソリューション: 調整可能なパラメタとタイマは、NETBLTによって勧められたものに類似するように変更されました。
Packet Size
パケットサイズ
In a tactical environment, channel conditions change rapidly. Continuously transmitting large packets under 10e-3 BER conditions reduces effective throughput.
戦術の環境で、チャンネル状態は急速に変化します。 絶え間なく10e-3 BER状態の下に大きいパケットを伝えると、有効なスループットは減らされます。
Solution: Packet sizes are dynamically adjusted based upon the success of the buffer transfers. If 99 percent of all packets within a buffer are received successfully, packet size can be increased to a negotiated value. If 50 percent or more of all packets within a buffer are not successfully delivered, the packet size can be decreased to a negotiated value.
ソリューション: パケットサイズはダイナミックにバッファ転送の成功に基づいた状態で調整されます。 首尾よくバッファの中のすべてのパケットの99パーセントを受け取るなら、交渉された値にパケットサイズを増強できます。 バッファの中の50パーセントか一層のすべてのパケットが首尾よく提供されるというわけではないなら、パケットサイズは交渉された値と減少できます。
2. PROTOCOL DESCRIPTION
2. プロトコル記述
Throughout this document the term packet is used to describe a datagram that includes all network overhead. A block is used to describe information, without any network encapsulation.
このドキュメント中では、用語パケットは、すべてのネットワークオーバーヘッドを含んでいるデータグラムについて説明するのに使用されます。 ブロックは、少しもネットワークカプセル化なしで情報について説明するのに使用されます。
The original source files for TFTP, as downloaded from ftp.uu.net, were modified to implement the ETFTP/NETBLT protocol. These same files are listed in "UNIX Network Programming" [5].
TFTPのためのftp.uu.netからダウンロードする一次資料ファイルは、ETFTP/NETBLTプロトコルを実装するように変更されました。 これらの同じファイルは「UNIXネットワーク・プログラミング」[5]にリストアップされています。
ETFTP was implemented for operations under the Santa Cruz Operations (SCO) UNIX. In the service file, "/etc/services", an addition was made to support "etftp" at a temporary well known port of "1818" using "UDP" protocol. The file, "/etc/inetd.conf", was modified so the "inetd" program could autostart the "etftpd" server when a
ETFTPはサンタクルスOperations(SCO)UNIXの下における操作のために実装されました。 サービスファイル、"/etc/services"では、追加は、「1818」の一時的なよく知られているポートで"UDP"プロトコルを使用することで"etftp"をサポートさせられました。 aであるときに、"inetd"プログラムが"etftpd"サーバをautostartすることができるように、ファイル"/etc/inetd.conf"は変更されました。
Polites, Wollman & Woo Experimental [Page 5] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[5ページ]RFC1986に言い寄ってください。
connection request came in on the well known port.
接続要求はよく知られているポートに参加しました。
As stated earlier, the transport layer for ETFTP is UDP, which will not be discussed further here. This client server application layer protocol is NETBLT, with four notable differences.
より早く述べられるように、ETFTPのためのトランスポート層はUDPです。(ここでさらにそのUDPについて議論しないでしょう)。 このクライアントサーバ・アプリケーション層のプロトコルは4つの注目に値する違いがあるNETBLTです。
The first change is that this NETBLT protocol is implemented on top of the UDP layer. This allowed the NETBLT concepts to be tested without modifying the operating system's transport or network layers. Table 2, "Four Layer Protocol Model," shows the protocol stack for FTP, TFTP and ETFTP.
最初の変化はこのNETBLTプロトコルがUDP層の上で実装されるということです。 これは、NETBLT概念がオペレーティングシステムの輸送かネットワーク層を変更しないでテストされるのを許容しました。 「4層のプロトコルモデル」というテーブル2はFTP、TFTP、およびETFTPのためにプロトコル・スタックを見せています。
Table 2: Four Layer Protocol Model
テーブル2: 4層のプロトコルモデル
+---------------------------------------------------------------+ | PROTOCOL STACK | +---------------+---------------+---------------+---------------+ |APPLICATION |FTP |TFTP |ETFTP/NETBLT | +---------------+---------------+---------------+---------------+ |TRANSPORT |TCP |UDP |UDP | +---------------+---------------+---------------+---------------+ |NETWORK |IP | +---------------+---------------+---------------+---------------+ |LINK |Ethernet, SLIP, AX.25 | +---------------+---------------+---------------+---------------+
+---------------------------------------------------------------+ | プロトコル・スタック| +---------------+---------------+---------------+---------------+ |アプリケーション|FTP|TFTP|ETFTP/NETBLT| +---------------+---------------+---------------+---------------+ |輸送|TCP|UDP|UDP| +---------------+---------------+---------------+---------------+ |ネットワーク|IP| +---------------+---------------+---------------+---------------+ |リンク|イーサネット、メモ用紙、斧.25| +---------------+---------------+---------------+---------------+
The second change is a carryover from TFTP, which allows files to be transferred in netascii or binary modes. A new T bit flag is assigned to the reserved field of the OPEN message type.
2番目の変化はTFTPからの繰越しです。(TFTPは、ファイルがnetasciiかバイナリ・モードで移されるのを許容します)。 新しいT噛み付いている旗はオープンメッセージタイプの予約された分野に割り当てられます。
The third change is to re-negotiate the DATA packet size. This change affects the OPEN, NULL-ACK, and CONTROL_OK message types. A new R bit is assigned to the reserved field of the OPEN message type.
3番目の変化はDATAパケットサイズを再交渉することになっています。 この変化はオープン、NULL-ACK、およびCONTROL_OKメッセージタイプに影響します。 新しいRビットはオープンメッセージタイプの予約された分野に割り当てられます。
The fourth change is the addition of two new fields to the OPEN message type. The one field is a two byte integer for radio delay in seconds, and the next field is two bytes of padding.
4番目の変化はオープンメッセージタイプへの2つの新しい分野の追加です。 1つの分野が秒のラジオ遅れのための2バイトの整数です、そして、次の分野は2バイトの詰め物です。
The ETFTP data encapsulation is shown in Table 3, "ETFTP Data Encapsulation,". The Ethernet, SLIP, and AX.25 headers are mutually exclusive. They are stripped off and added by the appropriate hardware layer.
ETFTPデータカプセル化で目立ちます。Table3、「ETFTPデータカプセル化。」 イーサネット、SLIP、およびAX.25ヘッダーは互いに排他的です。 それらは、全部はぎ取られて、適切なハードウェア層のそばで加えられます。
Polites, Wollman & Woo Experimental [Page 6] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[6ページ]RFC1986に言い寄ってください。
Table 3: ETFTP Data Encapsulation
テーブル3: ETFTPデータカプセル化
+------------+------------+------------+------------+-----------+ |Ethernet(14)| | |ETFTP/ | | |SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) | |AX.25(20) | | | | | +------------+------------+------------+------------+-----------+
+------------+------------+------------+------------+-----------+ |イーサネット(14)| | |ETFTP/| | |メモ用紙(2)|IP(20)|UDP(8)|NETBLT(24)|データ(1448)| |斧の.25(20)| | | | | +------------+------------+------------+------------+-----------+
2.1 MESSAGE TYPES AND FORMATS
2.1 メッセージタイプと形式
Here are the ETFTP/NETBLT message types and formats.
ここに、ETFTP/NETBLTメッセージタイプと形式があります。
MESSAGES VALUES
OPEN 0 Client request to open a new connection
RESPONSE 1 Server positive acknowledgment for OPEN
KEEPALIVE 2 Reset the timer
QUIT 3 Sender normal Close request
QUITACK 4 Receiver acknowledgment of QUIT
ABORT 5 Abnormal close
DATA 6 Sender packet containing data
LDATA 7 Sender last data block of a buffer
NULL-ACK 8 Sender confirmation of CONTROL_OK changes
CONTROL 9 Receiver request to
GO 0 Start transmit of next buffer
OK 1 Acknowledge complete buffer
RESEND 2 Retransmit request
REFUSED 10 Server negative acknowledgment of OPEN
DONE 11 Receiver acknowledgment of QUIT.
MESSAGES VALUES OPEN0Clientは、OPEN KEEPALIVE2ResetタイマQUITのために新しい接続RESPONSE1Server肯定応答を開くために、3のSenderの正常なCloseがデータLDATA7Senderを含むQUIT ABORT5のAbnormalの近いDATA6SenderパケットのQUITACK4Receiver承認を要求するよう要求します; CONTROL_OKバッファNULL-ACK8Sender確認に関する最後のデータ・ブロックはCONTROL9Receiver要求を0StartがQUITのOPEN DONE11Receiver承認の次のバッファOK1Acknowledgeの完全なバッファRESEND2Retransmit要求REFUSED10Server否定応答について送信するGOに変えます。
Packets are "longword-aligned", at four byte word boundaries. Variable length strings are NULL terminated, and padded to the four byte boundary. Fields are listed in network byte order. All the message types share a common 12 byte header. The common fields are:
パケットは「ロングワードで並べられた」4バイトで語境界です。 可変長ストリングは4バイト境界に終えられて、水増しされたNULLです。 分野はネットワークバイトオーダーで記載されています。 すべてのメッセージタイプが12バイトの一般的なヘッダーを共有します。 共同耕地は以下の通りです。
Checksum IP compliant checksum Version Current version ID Type NETBLT message type Length Total byte length of packet Local Port My port ID Foreign Port Remote port ID Padding Pad as necessary to 4 byte boundary
4バイト境界に必要に応じてパケットLocal Port MyポートID Foreign Port RemoteポートID Padding PadのIP対応することのチェックサムのType NETBLTメッセージタイプLength TotalバイトのチェックサムバージョンCurrentバージョンID長さ
The OPEN and RESPONSE messages are similar and shown in Table 4, "OPEN and RESPONSE Message Types,". The client string field is used to carry the filename to be transferred.
オープン同様であり、Table4に示されたRESPONSEメッセージ、「戸外と応答メッセージタイプ。」 クライアント文字列欄は、移すためにファイル名を運ぶのに使用されます。
Polites, Wollman & Woo Experimental [Page 7] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[7ページ]RFC1986に言い寄ってください。
Table 4: OPEN and RESPONSE Message Types
テーブル4: 戸外と応答メッセージタイプ
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 ID |
+---------------+---------------+---------------+---------------+
|Buffer size |
+---------------+---------------+---------------+---------------+
|Transfer size |
+---------------+---------------+---------------+---------------+
|DATA Packet size |Burstsize |
+---------------+---------------+---------------+---------------+
|Burstrate |Death Timer Value |
+---------------+---------------+---------------+---------------+
|Reserved(MBZ) |R|T|C|M|Maximum # Outstanding Buffers |
+---------------+---------------+---------------+---------------+
|*Radio Delay |*Padding |
+---------------+---------------+---------------+---------------+
|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 Packetサイズ|Burstsizeします。| +---------------+---------------+---------------+---------------+ |Burstrate|死亡タイマ価値| +---------------+---------------+---------------+---------------+ |予約されます(MBZ)。|R|T|C|M|最大の#傑出しているバッファ| +---------------+---------------+---------------+---------------+ |*ラジオ遅れ|*詰め物| +---------------+---------------+---------------+---------------+ |クライアントストリング…|ロングワード整列詰め物| +---------------+---------------+---------------+---------------+
Connection ID The unique connection number
Buffer size Bytes per buffer
Transfer size The length of the file in bytes
DATA Packet size Bytes per ETFTP block
Burstsize Concatenated packets per burst
Burstrate Milliseconds per burst
Death Timer Seconds before closing idle links
Reserved M bit is mode: 0=read/put, 1=write/get
C bit is checksum: 0=header, 1=all
*T bit is transfer: 0=netascii, 1=binary
*R bit is re-negotiate: 0=off, 1=on
Max # Out Buffs Maximum allowed un-acknowledged buffers
Radio Delay *Seconds of delay from send to receive
Padding *Unused
Client String Filename.
バッファTransferサイズあたりの接続IDユニークな接続数のBufferサイズBytesに、Reserved Mが噛み付いた使用されていないリンクを閉じる前の炸裂Death Timer Secondsあたりの炸裂Burstrate MillisecondsあたりのETFTPブロックBurstsize ConcatenatedパケットあたりのバイトDATA PacketサイズBytesのファイルの長さはモードです: 0 =が読まれるか、または置かれて、=がCビットを書くか、または手に入れる1はチェックサムです: 0 = すべての*T1歳のヘッダー=ビットが転送です: 0=netascii、1=バイナリー*Rビットは再交渉することです: 0 = オフです、マックス#Out Buffs Maximumの上の=が不承認のバッファにRadio Delay*秒の遅れを許容した1は、Padding*未使用のClient String Filenameを受け取るために発信します。
The KEEPALIVE, QUITACK, and DONE messages are identical to the common header, except for the message type values. See Table 5, "KEEPALIVE, QUITACK, and DONE Message Types,".
メッセージタイプ値以外の一般的なヘッダーに、KEEPALIVE、QUITACK、およびDONEメッセージは同じです。 テーブル5、「KEEPALIVE、QUITACK、およびされたメッセージタイプ」を見てください。
Polites, Wollman & Woo Experimental [Page 8] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[8ページ]RFC1986に言い寄ってください。
Table 5: KEEPALIVE, QUITACK, and DONE Message Types
テーブル5: KEEPALIVE、QUITACK、およびされたメッセージタイプ
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 +---------------+---------------+---------------+---------------+ |チェックサム|バージョン|タイプ| +---------------+---------------+---------------+---------------+ |長さ|地方のポート| +---------------+---------------+---------------+---------------+ |外国ポート|ロングワード整列詰め物| +---------------+---------------+---------------+---------------+
The QUIT, ABORT, and REFUSED messages allow a string field to carry the reason for the message. See Table 6, "QUIT, ABORT, and REFUSED Message Types,".
QUIT、ABORT、およびREFUSEDメッセージで、文字列欄はメッセージの理由を運ぶことができます。 「やめてください、そして、中止になってください、そして、メッセージタイプに拒否された」というテーブル6を見てください。
Table 6: QUIT, ABORT, and REFUSED Message Types
テーブル6: やめてください、そして、中止になってください、そして、メッセージタイプに拒否されました。
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/REFUSED . . . |
+---------------+---------------+---------------+---------------+
|. . . |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 +---------------+---------------+---------------+---------------+ |チェックサム|バージョン|タイプ| +---------------+---------------+---------------+---------------+ |長さ|地方のポート| +---------------+---------------+---------------+---------------+ |外国ポート|ロングワード整列詰め物| +---------------+---------------+---------------+---------------+ |やめられて、/が…を中止になったか、または拒否したので、推論してください。| +---------------+---------------+---------------+---------------+ |. . . |ロングワード整列詰め物| +---------------+---------------+---------------+---------------+
The DATA and LDATA messages make up the bulk of the messages transferred. The last packet of each buffer is flagged as an LDATA message. Each and every packet of the last buffer has the reserved L bit set. The highest consecutive sequence number is used for the acknowledgment of CONTROL messages. It should contain the ID number of the current CONTROL message being processed. Table 7, "DATA and LDATA Message Types,", shows the DATA and LDATA formats.
メッセージがメッセージの大半にするDATAとLDATAは移しました。 それぞれのバッファの最後のパケットはLDATAメッセージとして旗を揚げられます。 最後のバッファのありとあらゆるパケットで、予約されたLビットを設定します。 最も高い連続した一連番号はCONTROLメッセージの承認に使用されます。 それは処理される現在のCONTROLメッセージのID番号を含むべきです。 ショーのDATAとLDATAは、テーブル7、「データとLDATAメッセージタイプ」とフォーマットします。
Polites, Wollman & Woo Experimental [Page 9] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[9ページ]RFC1986に言い寄ってください。
Table 7: DATA and LDATA Message Types
テーブル7: データとLDATAメッセージタイプ
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 The first buffer number starts at 0 Hi Con Seq Num The acknowledgment for CONTROL messages Packet Number The first packet number starts at 0 Data Checksum Checksum for data area only Reserved L: the last buffer bit: 0=false, 1=true
Numberをバッファリングしてください。最初のバッファ数は最初のパケット番号がデータ領域Reserved Lだけのために0Data Checksum Checksumで始動するCONTROLメッセージPacket Numberのために0Hi Con Seqヌムで承認を始めます: 最後のバッファビット: 0は= 本当に偽、1と等しいです。
The NULL-ACK message type is sent as a response to a CONTROL_OK message that modifies the current packet size, burstsize, or burstrate. In acknowledging the CONTROL_OK message, the sender is confirming the change request to the new packet size, burstsize, or burstrate. If no modifications are requested, a NULL-ACK message is unnecessary. See Table 8, "NULL-ACK Message Type," for further details.
タイプが現在のパケットサイズを変更するCONTROL_OKメッセージへの応答として送られて、burstsizeするというNULL-ACKメッセージ、またはburstrate。 CONTROL_OKメッセージであり、送付者が新しいパケットサイズに変更要求を確認していて、burstsizeすると認めるか、またはburstrateで。 変更が全く要求されないなら、NULL-ACKメッセージは不要です。 Table8、「ヌルACKメッセージタイプ」を詳細に関して見てください。
Table 8: NULL-ACK Message Type
テーブル8: ヌルACKメッセージタイプ
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 Burstsize |
+---------------+---------------+---------------+---------------+
|New Burstrate |*New DATA Packet size |
+---------------+---------------+---------------+---------------+
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|新しいBurstsize| +---------------+---------------+---------------+---------------+ |新しいBurstrate|*新しいDATA Packetサイズ| +---------------+---------------+---------------+---------------+
Polites, Wollman & Woo Experimental [Page 10] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[10ページ]RFC1986に言い寄ってください。
The CONTROL messages have three subtypes: GO, OK, and RESEND as shown in Tables 9-12. The CONTROL message common header may be followed by any number of longword aligned subtype messages.
CONTROLメッセージには、3血液型亜型があります: GO、OKとTables9-12で見せられるRESEND。 いろいろなロングワードの並べられた「副-タイプ」メッセージがCONTROLのメッセージの一般的なヘッダーのあとに続くかもしれません。
Table 9: CONTROL Message Common Header
テーブル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 +---------------+---------------+---------------+---------------+ |チェックサム|バージョン|タイプ| +---------------+---------------+---------------+---------------+ |長さ|地方のポート| +---------------+---------------+---------------+---------------+ |外国ポート|ロングワード整列詰め物| +---------------+---------------+---------------+---------------+
Table 10: CONTROL_GO Message Subtype
テーブル10: コントロール_はSubtypeを通信させに行きます。
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
+---------------+---------------+---------------+---------------+
|Subtype |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 +---------------+---------------+---------------+---------------+ |Subtype|詰め物|一連番号| +---------------+---------------+---------------+---------------+ |バッファ数| +---------------+---------------+---------------+---------------+
Table 11: CONTROL_OK Message Subtype
テーブル11: コントロール_OKメッセージSubtype
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
+---------------+---------------+---------------+---------------+
|Subtype |Padding |Sequence Number |
+---------------+---------------+---------------+---------------+
|Buffer Number |
+---------------+---------------+---------------+---------------+
|New Offered Burstsize |New Offered Burstrate |
+---------------+---------------+---------------+---------------+
|Current Control Timer Value |*New DATA Packet size |
+---------------+---------------+---------------+---------------+
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 +---------------+---------------+---------------+---------------+ |Subtype|詰め物|一連番号| +---------------+---------------+---------------+---------------+ |バッファ数| +---------------+---------------+---------------+---------------+ |新しい提供されたBurstsize|新しい提供されたBurstrate| +---------------+---------------+---------------+---------------+ |現在のコントロールタイマ価値|*新しいDATA Packetサイズ| +---------------+---------------+---------------+---------------+
Polites, Wollman & Woo Experimental [Page 11] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[11ページ]RFC1986に言い寄ってください。
Table 12: CONTROL_RESEND Message Subtype
テーブル12: コントロール_はメッセージSubtypeを再送します。
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
+---------------+---------------+---------------+---------------+
|Subtype |Padding |Sequence Number |
+---------------+---------------+---------------+---------------+
|Buffer Number |
+---------------+---------------+---------------+---------------+
|Number of Missing Packets |Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
|Packet Number (2 bytes) |. . . |
+---------------+---------------+---------------+---------------+
|. . . |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 +---------------+---------------+---------------+---------------+ |Subtype|詰め物|一連番号| +---------------+---------------+---------------+---------------+ |バッファ数| +---------------+---------------+---------------+---------------+ |なくなったパケットの数|ロングワード整列詰め物| +---------------+---------------+---------------+---------------+ |パケットNumber(2バイト)|. . . | +---------------+---------------+---------------+---------------+ |. . . |ロングワード整列詰め物| +---------------+---------------+---------------+---------------+
2.2 ETFTP COMMAND SET
2.2 ETFTPコマンドセット
Being built from TFTP source code, ETFTP shares a significant portion of TFTP's design. Like TFTP, ETFTP does NOT support user password validation. The program does not support changing directories (i.e. cd), neither can it list directories, (i.e. ls). All filenames must be given in full paths, as relative paths are not supported. The internal finite state machine was modified to support NETBLT message types.
TFTPソースコードから建てられて、ETFTPはTFTPのデザインの重要な部分を共有します。 TFTPのように、ETFTPは、ユーザパスワードが合法化であるとサポートしません。 プログラムはディレクトリ(すなわち、cd)を変化に支えないで、どちらも、それはディレクトリ、(すなわち、ls)を記載できません。 相対パスをサポートしないとき、フルパスですべてのファイル名を与えなければなりません。 内部の有限状態機械は、NETBLTメッセージタイプをサポートするように変更されました。
The NETBLT protocol is implemented as closely as possible to what is described in RFC 998, with a few exceptions. The client string field in the OPEN message type is used to carry the filename of the file to be transferred. Netascii or binary transfers are both supported. If enabled, new packet sizes, burstsizes, and burstrates are re- negotiated downwards when half or more of the blocks in a buffer require retransmission. If 99% of the packets in a buffer is successfully transferred without any retransmissions, packet size is re-negotiated upwards.
NETBLTプロトコルはできるだけ密接にいくつかの例外があるRFC998で説明されることに実装されます。 オープンメッセージタイプのクライアント文字列欄は、移すためにファイルのファイル名を運ぶのに使用されます。 Netasciiか2進の転送がともにサポートされます。 可能にされて、新しいパケットサイズであるならburstsizesする、半分かバッファでの一層のブロックが「再-トランスミッション」を必要とするとき、burstratesは下向きに再交渉されます。 少しも「再-トランスミッション」なしでバッファのパケットの99%を首尾よく移すなら、上向きにパケットサイズを再交渉します。
The interactive commands supported by the client process are similar to TFTP. Here is the ETFTP command set. Optional parameters are in square brackets. Presets are in parentheses.
クライアントプロセスで後押しされている対話的なコマンドはTFTPと同様です。 ここに、ETFTPコマンドセットがあります。 角括弧には任意のパラメタがあります。 あらかじめセットする、括弧に、あります。
? help, displays command list ascii mode ascii, appends CR-LF per line autoadapt toggles backoff function (on) baudrate baud baud rate (16000 bits/sec) binary mode binary, image transfer blocksize bytes packet size in bytes (512 bytes/block) bufferblock blks buffer size in blocks (128 blocks/buff) burstsize packets burst size in packets (8 blocks/burst)
--、助け、ディスプレイがコマンドがASCIIモードASCIIを記載して、CR-LFを追加する単位backoff機能(on) baudrateボーボーレート(16000ビット/秒)バイナリ・モード2進でautoadaptトグルを裏打ちして、画像転送が(128人のブロック/ファン)がパケット放出量をburstsizeするブロックのバイト(512バイト/ブロック)のbufferblock blksの、よりもみ皮製のサイズにおけるバイトパケットサイズをblocksizeするパケット(8回のブロック/炸裂)
Polites, Wollman & Woo Experimental [Page 12] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[12ページ]RFC1986に言い寄ってください。
connect host [p] establish connection with host at port p exit ends program get rfile lfile copy remote file to local file help same as ? mode choice set transfer mode (binary) multibuff num number of buffers (2 buffers) put lfile rfile copy local file to remote file quit same as exit radiodelay sec transmission delay in seconds (2 sec) status display network parameters trace toggles debug display (off).
トランスミッションが状態ディスプレイ回路パラメータがたどる秒(2秒)に遅らせる出口radiodelay秒がデバッグディスプレイ(off)を切り換えるとき、同じ状態でポートp出口エンドプログラムがバッファ(2つのバッファ)のモード選択セット転送モード(バイナリー)multibuff num番号がlfile rfileコピーローカルファイルをリモートファイルにつけるのと同じローカルファイルヘルプへのリモートファイルがやめたrfile lfileコピーを届ける[p]がホストとの接続を確立するホストに接してください。
2.3 DATA TRANSFER AND FLOW CONTROL
2.3のデータ転送とフロー制御
This is the scenario between client and server transfers:
これはクライアントとサーバ転送の間のシナリオです:
Client sends OPEN for connection, blocksize, buffersize, burstsize, burstrate, transfer mode, and get or put. See M bit of reserved field.
blocksizeして、buffersizeして、burstsizeして、burstrateして、モードを移して、得るか、または置かれて、クライアントは接続のためにオープンを送ります。 Mが予約された分野について噛み付かれるのを見てください。
Server sends a RESPONSE with the agreed parameters.
サーバは同意されたパラメタがあるRESPONSEを送ります。
Receiver sends a CONTROL_GO request sending of first buffer.
受信機で、GOが要求するCONTROL_は最初のバッファを発信させます。
Sender starts transfer by reading the file into multiple memory buffers. See Figure 1, "File Segmentation,". Each buffer is divided according to the number of bytes/block. Each block becomes a DATA packet, which is concatenated according to the blocks/burst. Bursts are transmitted according to the burstrate. Last data block is flagged as LDATA type.
送付者は、複数のメモリ・バッファからファイルを読み取ることによって、転送を始めます。 「分割をファイルしてください」という図1を参照してください。 バイト数/ブロックに応じて、各バッファは分割されます。 各ブロックはDATAパケットになります。(それは、ブロックに従って連結されるか、または押し破かれます)。 burstrateに従って、炸裂は伝えられます。 LDATAがタイプするように最後のデータ・ブロックは旗を揚げられます。
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | | | 0 | | L | | 4 | | 3 | ---- | 2 | | 1 | | 0 | | | | +---+ +---+ +---+ +---+ +---+ +---+ +---+ | | +-| | --> +---+ +---+ +---+ +---+ +---+ | | --> | 1 | | L | | 3 | ---- | 2 | | 1 | | 0 | +---+ +---+ +---+ +---+ +---+ +---+ +---+ File Multi Buffers Blocks per Burst
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | | | 0 | | L| | 4 | | 3 | ---- | 2 | | 1 | | 0 | | | | +---+ +---+ +---+ +---+ +---+ +---+ +---+ | | +-| | -->+---+ +---+ +---+ +---+ +---+ | | -->| 1 | | L| | 3 | ---- | 2 | | 1 | | 0 | +---+ +---+ +---+ +---+ +---+ +---+ +---+ 1炸裂あたりのファイルマルチバッファブロック
Figure 1. File Segmentation
図1。 ファイル分割
Receiver acknowledges buffer as CONTROL_OK or CONTROL_RESEND.
受信機はCONTROL_OKかCONTROL_RESENDとしてバッファを承認します。
If blocks are missing, a CONTROL_RESEND packet is transmitted. If half or more of the blocks in a buffer are missing, an adaptive algorithm is used for the next buffer transfer. If no blocks are missing, a CONTROL_OK packet is transmitted.
ブロックがなくなるなら、CONTROL_RESENDパケットは伝えられます。 半分かバッファでの一層のブロックがなくなるなら、適応型のアルゴリズムは次のバッファ転送に使用されます。 どんなブロックもなくならないなら、CONTROL_OKパケットは伝えられます。
Polites, Wollman & Woo Experimental [Page 13] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[13ページ]RFC1986に言い寄ってください。
Sender re-transmits blocks until receipt of a CONTROL_OK. If the adaptive algorithm is set, then new parameters are offered, in the CONTROL_OK message. The priority of the adaptive algorithm is:
送付者はCONTROL_OKの領収書までブロックを再送します。 適応型のアルゴリズムを設定するなら、CONTROL_OKメッセージで新しいパラメタを提供します。 適応型のアルゴリズムの優先権は以下の通りです。
- Reduce packetsize by half (MIN = 16 bytes/packet) - Reduce burstsize by one (MIN = 1 packet/burst) - Reduce burstrate to actual tighttimer rate
- 減少、packetsizeする、半分で、(MIN=16のバイト/パケット)--減少するのは1時までにburstsizeされます(MINは1回のパケット/炸裂と等しいです)--burstrateを実際の、よりtighttimerなレートまで減少させてください。
If new parameters are valid, the sender transmits a NULL-ACK packet, to confirm the changes.
新しいパラメタが有効であるなら、送付者は、変化を確認するためにNULL-ACKパケットを伝えます。
Receiver sends a CONTROL_GO to request sending next buffer.
受信機は次のバッファを送る要求にCONTROL_GOを送ります。
At end of transfer, sender sends a QUIT to close the connection.
転送の終わりに、送付者は、接続を終えるためにQUITを送ります。
Receiver acknowledges the close request with a DONE packet.
受信機はDONEパケットで厳密な要求を承諾します。
2.4 TUNABLE PARAMETERS
2.4 調整可能なパラメタ
These parameters directly affect the throughput rate of ETFTP.
これらのパラメタは直接ETFTPの押出量に影響します。
Packetsize The packetsize is the number of 8 bit bytes per packet. This number refers to the user data bytes in a block, (frame), exclusive of any network overhead. The packet size has a valid range from 16 to 1,448 bytes. The Maximum Transfer Unit (MTU) implemented in most commercial network devices is 1,500 bytes. The de-facto industry standard is 576 byte packets.
Packetsizeする、packetsizeする、1パケットあたりの8ビットのバイトの数はそうです。 この数はどんなネットワークオーバーヘッドを除いてブロック、(フレーム)のユーザデータ・バイトについて言及します。 パケットサイズには、16〜1,448バイトの有効枠があります。 ほとんどの市販のネットワークデバイスで実装されたMaximum Transfer Unit(MTU)は1,500バイトです。 デファクト業界基準は576バイトのパケットです。
Bufferblock The bufferblock is the number of blocks per buffer. Each implementation may have restrictions on available memory, so the buffersize is calculated by multiplying the packetsize times the bufferblocks.
Bufferblock、bufferblockは1バッファあたりのブロックの数です。 したがって、各実装が利用可能なメモリに制限を持っているかもしれない、buffersizeする、増えることによって計算される、回をpacketsizeする、bufferblocks。
Baudrate The baudrate is the bits per second transfer rate of the slowest link (i.e., the radios). The baudrate sets the speed of the sending process. The sending process cannot detect the actual speed of the network, so the user must set the correct baudrate.
Baudrate、baudrateは最も遅いリンク(すなわち、ラジオ)のbps転送レートです。 baudrateは送付プロセスの速度を設定します。 送付プロセスがネットワークの実際の速度を検出できないので、ユーザは正しいbaudrateを設定しなければなりません。
Burstsize The burstsize in packets per burst sets how many packets are concatenated and burst for transmission efficiency. The burstsize times the packetsize must not exceed the available memory of any intervening network devices. On the Ethernet portion of the network, all the packets are sent almost instantaneously. It is necessary to wait for the network to drain down its memory buffers, before the next burst is sent. The sending process needs to regulate the rate used to place packets into the network.
Burstsizeする、burstsizeする、1炸裂あたりのパケットでは、いくつのパケットが連結されるか、そして、炸裂を伝達効率に設定します。 回をburstsizeする、packetsizeする、どんな介入しているネットワークデバイスの利用可能なメモリも超えてはいけません。 ネットワークのイーサネット一部に、ほとんど即座にすべてのパケットを送ります。 次の炸裂を送る前にネットワークがメモリ・バッファの下側に排水するのを待つのが必要です。 送付プロセスは、パケットをネットワークに置くのに使用されるレートを規制する必要があります。
Polites, Wollman & Woo Experimental [Page 14] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[14ページ]RFC1986に言い寄ってください。
Radiodelay The radiodelay is the time in seconds per burst it takes to synchronize with the radio controllers. Any additional hardware delays should be set here. It is the aggregate delay of the link layer, such as transmitter key-up, FEC, crypto synchronization, and propagation delays.
Radiodelay、radiodelayは1ラジオコントローラに連動するのに要する炸裂あたりの秒の時間です。 どんな追加ハードウェア遅れもここに設定されるべきです。 それは上に送信機キーや、FECや、暗号同期や、伝播遅延などのリンクレイヤの集合遅れです。
These parameters above are used to calculate a burstrate, which is the length of time it takes to transmit one burst. The ov is the overhead of 72 bytes per packet of network encapsulation. A byte is defined as 8 bits. The burstrate value is:
上記のこれらのパラメタは、burstrateについて計算するのに使用されます。(burstrateは1回の炸裂を伝えるにはかかる時間の長さです)。 ovはネットワークカプセル化のパケットあたり72バイトのオーバーヘッドです。 1バイトは8ビットと定義されます。 burstrate値は以下の通りです。
burstrate = (packetsize+ov)*burstsize*8/baudrate
burstrate=(+ ovをpacketsizeします)*は*8/baudrateをburstsizeします。
In a effort to calculate the round trip time, when data is flowing in one direction for most of the transfer, the OPEN and RESPONSE message types are timed, and the tactical radio delays are estimated. Using only one packet in each direction to estimate the rate of the link is statistically inaccurate. It was decided that the radio delay should be a constant provided by the user interface. However, a default value of 2 seconds is used. The granularity of this value is in seconds because of two reasons. The first reason is that the UNIX supports a sleep function in seconds only. The second reason is that in certain applications, such as deep space probes, a 16-bit integer maximum of 32,767 seconds would suffice.
データが転送の大部分の一方向に流れる周遊旅行時間について計算する取り組みでは、オープンとRESPONSEメッセージタイプは調節されています、そして、戦術のラジオ遅れは見積もられています。 リンクのレートを見積もるのに各方向への1つのパケットだけを使用するのは統計的に不正確です。 ラジオ遅れがユーザーインタフェースによって提供された定数であるべきであると決められました。 しかしながら、2秒のデフォルト値は使用されています。 秒に、この価値の粒状が2つの理由のためにあります。 最初の理由はUNIXが秒だけに睡眠機能をサポートするということです。 2番目の理由は宇宙空間徹底的調査などのある応用では、3万2767秒の16ビットの整数最大が十分であるだろうということです。
2.5 DELAYS AND TIMERS
2.5 遅れとタイマ
From these parameters, several timers are derived. The control timer is responsible for measuring the per buffer rate of transfer. The SENDER copy is nicknamed the loosetimer.
これらのパラメタから、数個のタイマが引き出されます。 制御タイマが測定するのに原因となる、転送のバッファ速度単位で。 SENDERコピーはloosetimerと愛称で呼ばれます。
loosetimer = (burstrate+radiodelay)*bufferblock/burstsize
loosetimer=(burstrate+radiodelay)*bufferblock/burstsize
The RECEIVER copy of the timer is nicknamed the tighttimer, which measures the elapsed time between CONTROL_GO and CONTROL_OK packets. The tighttimer is returned to the SENDER to allow the protocol to adjust for the speed of the network.
タイマのRECEIVERコピーはtighttimerと愛称で呼ばれます。(tighttimerはCONTROL_GOとCONTROL_OKパケットの間で経過時間を測定します)。 プロトコルがネットワークの速度のために適応するのを許容するためにtighttimerをSENDERに返します。
The retransmit timer is responsible for measuring the network receive data function. It is used to set an alarm signal (SIGALRM) to interrupt the network read. The retransmit timer (wait) is initially set to be the greater of twice the round trip or 4 times the radiodelay, plus a constant 5 seconds.
再送信タイマはネットワーク受信データ機能を測定するのに原因となります。 それは、ネットワークを中断する(SIGALRM)が読むという警急信号を設定するのに使用されます。 初めは、二度で再送信タイマ(待っている)が周遊旅行かradiodelayの4倍、および一定の5秒よりすばらしいように設定されます。
Polites, Wollman & Woo Experimental [Page 15] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[15ページ]RFC1986に言い寄ってください。
wait = MAX ( 2*roundtriptime, 4*radiodelay ) + 5 seconds
+5秒の待ち=MAX(2*roundtriptime、4*radiodelay)
and
そして
alarm timeout = wait.
アラームタイムアウトは待ちと等しいです。
Each time the same read times out, a five second backoff is added to the next wait. The backoff is necessary because the initial user supplied radiodelay, or the initial measured round trip time may be incorrect.
その都度、同じくらいはbackoffが次の待ちに加えられる5秒に回を読みだしました。 初期のユーザがradiodelayを供給したので、backoffが必要であるか、または初期の測定周遊旅行時間は不正確であるかもしれません。
The retransmit timer is set differently for the RECEIVER during a buffer transfer. Before the arrival of the first DATA packet, the original alarm time out is used. Once the DATA packets start arriving, and for the duration of each buffer transfer, the RECEIVER alarm time out is reset to the expected arrival time of the last DATA packet (blockstogo) plus the delay (wait). As each DATA packet is received, the alarm is decremented by one packet interval. This same algorithm is used for receiving missing packets, during a RESEND.
再送信タイマはバッファ転送の間、RECEIVERに異なって設定されます。 最初のDATAパケットの到着の前に、オリジナルのアラームタイムアウトは使用されています。 一度、DATAパケットは到着し始めます、そして、それぞれのバッファ転送の持続時間において、RECEIVERアラームタイムアウトは最後のDATAパケット(blockstogo)の予想された到着時間と遅れにリセットされます(待ってください)。 それぞれのDATAパケットが受け取られているのに従って、アラームは1回のパケット間隔のそばで減少します。 この同じアルゴリズムは、RESENDの間、なくなったパケットを受けるのに使用されます。
alarmtimeout = blockstogo*burstrate/burstsize + wait
alarmtimeout=blockstogo*burstrate/burstsize+待ち
The death timer is responsible for measuring the idle time of a connection. In the ETFTP program, the death timer is set to be equal to the accumulated time of ten re-transmissions plus their associated backoffs. As such, the death timer value in the OPEN and RESPONSE message types is un-necessary. In the ETFTP program, this field could be used to transfer the radio delay value instead of creating the two new fields.
死亡タイマは接続の遊休時間を測定するのに原因となります。 ETFTPプログラムでは、10個の再トランスミッションとそれらの関連backoffsの蓄積された時間に死亡タイマが等しいように設定されます。 そういうものとして、オープンとRESPONSEメッセージタイプの死亡タイマ価値は不要です。 ETFTPプログラムでは、2つの新しい分野を作成することの代わりにラジオ遅れ価値を移すのにこの分野を使用できました。
The keepalive timer is responsible for resetting the death timer. This timer will trigger the sending of a KEEPALIVE packet to prevent the remote host from closing a connection due to the expiration of its death timer. Due to the nature of the ETFTP server process, a keepalive timer was not necessary, although it is implemented.
keepaliveタイマは死亡タイマをリセットするのに原因となります。 このタイマはリモートホストが死亡タイマの満了による接続を終えるのを防ぐKEEPALIVEパケットの発信の引き金となるでしょう。 ETFTPサーバプロセスの自然のために、それは実装されますが、keepaliveタイマは必要ではありませんでした。
2.6 TEST RESULTS
2.6 テスト結果
The NETBLT protocol has been tested on other high speed networks before, see RFC 1030 [6]. These test results in Tables 13 and 14, "ETFTP Performance," were gathered from files transferred across the network and LST-5C TACSAT radios. The radios were connected together via a coaxial cable to provide a "clean" link. A clean link is defined to a BER of 10e-5. The throughput rates are defined to be the file size divided by the elapsed time resulting in bits per second (bps). The elapsed time is measured from the time of the "get" or "put" command to the completion of the transfer. This is an all inclusive time measurement based on user perspective. It includes the
NETBLTプロトコルは以前他の高速ネットワークでテストされたことがあって、RFC1030[6]を見てください。 「ETFTPパフォーマンス」というTables13と14のこれらの試験の成績はネットワークの向こう側に移されたファイルとLST-5CのTACSATラジオから集められました。 ラジオは、「清潔な」リンクを提供するために同軸ケーブルを通して一緒に接続されました。 清潔なリンクは10e-5のBERと定義されます。 押出量は、bps(ビーピーエス)をもたらす経過時間が割られたファイルサイズになるように定義されます。 経過時間は「得る」か「置き」コマンドの時間から転送の完成に測定されます。 これはすべて、ユーザ見解に基づく包括的な時間測定です。 それは含んでいます。
Polites, Wollman & Woo Experimental [Page 16] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[16ページ]RFC1986に言い寄ってください。
connection time, transfer time, error recovery time, and disconnect time. The user concept of elapsed time is the length of time it takes to copy a file from disk to disk. These results show only the average performances, including the occasional packet re-transmissions. The network configuration was set as:
接続時間、転送時間、エラー回復時間、および分離時間。 経過時間のユーザ概念はディスクからディスクまでファイルをコピーするにはかかる時間の長さです。 これらの結果は時々のパケット再トランスミッションを含む平均した性能だけを示しています。 ネットワーク・コンフィギュレーションは以下として設定されました。
ETFTP Parameters:
ETFTPパラメタ:
Filesize 101,306 bytes Radiodelay 2 seconds Buffersize 16,384-131,072 bytes Packetsize 512-2048 bytes Burstsize 8-16 packets/burst
16,384-131,072バイトの10万1306バイトのRadiodelay2秒のBuffersizeのPacketsizeの512-2048バイトのBurstsize8-16パケット/炸裂をFilesizeします。
Gracilis PackeTen Parameters:
Gracilis PackeTenパラメタ:
0 TX Delay 400 milliseconds 1 P Persist 255 [range 1-255] 2 Slot Time 30 milliseconds 3 TX Tail 300 milliseconds 4 Rcv Buffers 8 2048 bytes/buffer 5 Idle Code Flag
0 テキサスDelay400ミリセカンド1P Persist255[範囲1-255]2Slot Time30ミリセカンド3テキサスTail300ミリセカンド4Rcv Buffers8 2048のバイト/バッファの5Idle Code Flag
Radio Parameters:
ラジオパラメタ:
Baudrate 16,000 bps Encryption on
1万6000ビーピーエス暗号化をBaudrateします。
Table 13: ETFTP Performance at 8 Packets/Burst in Bits/Second
テーブル13: ビット/秒における8回のパケット/炸裂のETFTPパフォーマンス
+-----------+-----------+-----------+-----------+-----------+ |buffersize |packetsize |packetsize |packetsize |packetsize | |(bytes) |2,048 bytes|1,448 bytes|1,024 bytes|512 bytes | +-----------+-----------+-----------+-----------+-----------+ | 16,384 | 7,153 | 6,952 | 6,648 | 5,248 | +-----------+-----------+-----------+-----------+-----------+ | 32,768 | 7,652 | 7,438 | 7,152 | 4,926 | +-----------+-----------+-----------+-----------+-----------+ | 65,536 | 8,072 | 8,752 | 8,416 | 5,368 | +-----------+-----------+-----------+-----------+-----------+ | 131,072 | 8,828 | 9,112 | 7,888 | 5,728 | +-----------+-----------+-----------+-----------+-----------+
+-----------+-----------+-----------+-----------+-----------+ |buffersizeします。|packetsizeします。|packetsizeします。|packetsizeします。|packetsizeします。| |(バイト) |2,048バイト|1,448バイト|1,024バイト|512バイト| +-----------+-----------+-----------+-----------+-----------+ | 16,384 | 7,153 | 6,952 | 6,648 | 5,248 | +-----------+-----------+-----------+-----------+-----------+ | 32,768 | 7,652 | 7,438 | 7,152 | 4,926 | +-----------+-----------+-----------+-----------+-----------+ | 65,536 | 8,072 | 8,752 | 8,416 | 5,368 | +-----------+-----------+-----------+-----------+-----------+ | 131,072 | 8,828 | 9,112 | 7,888 | 5,728 | +-----------+-----------+-----------+-----------+-----------+
Polites, Wollman & Woo Experimental [Page 17] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[17ページ]RFC1986に言い寄ってください。
Table 14: ETFTP Performance at 16 Packets/Burst in Bits/Second
テーブル14: ビット/秒における16回のパケット/炸裂のETFTPパフォーマンス
+-----------+-----------+-----------+-----------+-----------+ |buffersize |packetsize |packetsize |packetsize |packetsize | |(bytes) |2,048 bytes|1,448 bytes|1,024 bytes|512 bytes | +-----------+-----------+-----------+-----------+-----------+ | 16,384 | 5,544 | 5,045 | 4,801 | 4,570 | +-----------+-----------+-----------+-----------+-----------+ | 32,768 | 8,861 | 8,230 | 8,016 | 7,645 | +-----------+-----------+-----------+-----------+-----------+ | 65,536 | 9,672 | 9,424 | 9,376 | 8,920 | +-----------+-----------+-----------+-----------+-----------+ | 131,072 | 10,432 | 10,168 | 9,578 | 9,124 | +-----------+-----------+-----------+-----------+-----------+
+-----------+-----------+-----------+-----------+-----------+ |buffersizeします。|packetsizeします。|packetsizeします。|packetsizeします。|packetsizeします。| |(バイト) |2,048バイト|1,448バイト|1,024バイト|512バイト| +-----------+-----------+-----------+-----------+-----------+ | 16,384 | 5,544 | 5,045 | 4,801 | 4,570 | +-----------+-----------+-----------+-----------+-----------+ | 32,768 | 8,861 | 8,230 | 8,016 | 7,645 | +-----------+-----------+-----------+-----------+-----------+ | 65,536 | 9,672 | 9,424 | 9,376 | 8,920 | +-----------+-----------+-----------+-----------+-----------+ | 131,072 | 10,432 | 10,168 | 9,578 | 9,124 | +-----------+-----------+-----------+-----------+-----------+
2.7 PERFORMANCE CONSIDERATIONS
2.7 性能問題
These tests were performed across a tactical radio link with a maximum data rate of 16000 bps. In testing ETFTP, it was found that the delay associated with the half duplex channel turnaround time was the biggest factor in throughput performance. Therefore, every attempt was made to minimize the number of times the channel needed to be turned around. Obviously, the easiest thing to do is to use as big a buffer as necessary to read in a file, as acknowledgments occurred only at the buffer boundaries. This is not always feasible, as available storage on disk could easily exceed available memory. However, the current ETFTP buffersize is set at a maximum of 524,288 bytes.
これらのテストは16000ビーピーエスの最大のデータ信号速度との戦術のラジオリンクの向こう側に実行されました。 テストETFTPでは、半二重チャンネルターンアラウンドタイムに関連している遅れがスループット性能に関する最大の要因であることが見つけられました。 したがって、チャンネルが変えられるために必要とした回数を最小にするように最善の努力をしました。 明らかに、する中で最も簡単なことはファイルで読むのに必要なだけ大きいバッファを使用することです、承認がバッファ限界だけに起こったので。 ディスクにおける利用可能なストレージが容易に利用可能なメモリを超えるかもしれないので、これはいつも可能であるというわけではありません。 しかしながら、現在のETFTP buffersizeは最大52万4288バイトで用意ができています。
The larger packetsizes also improved performance. The limit on packetsize is based on the 1500 byte MTU of network store and forward devices. In a high BER environment, a large packetsize could be detrimental to success. By reducing the packetsize, even though it negatively impacts performance, reliability is sustained. When used in conjunction with FEC, both performance and reliability can be maintained at an acceptable level.
より大きいのはまた、向上した性能をpacketsizesします。 限界、オンである、packetsizeする、ネットワーク店と前進のデバイスの1500年のバイトのMTUに基づいています。 高いBER環境で、多大がpacketsizeするaは成功に有害であるかもしれません。 減少する、packetsizeする、否定的に性能に影響を与えますが、信頼性は持続しています。 FECに関連して使用されると、合格水準で性能と信頼性の両方を維持できます。
The burstsize translates into how long the radio transmitters are keyed to transmit. In ETFTP, the ideal situation is to have the first packet of a burst arrive in the radio transmit buffer, as the last packet of the previous burst is just finished being sent. In this way, the radio transmitter would never be dropped for the duration of one buffer. In a multi-user radio network, a full buffer transmission would be inconsiderate, as the transmit cycle could last for several minutes, instead of seconds. In measuring voice communications, typical transmit durations are on the order of five to twenty seconds. This means that the buffersize and burstsize could be adjusted to have similar transmission durations.
burstsizeする、無線送信機が伝わるようにどれくらい長い間合わせられるかに翻訳します。 ETFTPでは、理想的な状況は炸裂の最初のパケットをラジオに到着させるのがバッファを伝えます、前の炸裂の最後のパケットがただ送られ終わっているときことです。 このように、無線送信機は1つのバッファの持続時間のために決して下げられません。 サイクルを伝えてください。マルチユーザラジオ放送網において、完全なバッファトランスミッションが思いやりがないだろう、数分間続くことができました、秒の代わりに。 声のコミュニケーション的で、典型的に測定する際に、持続時間は伝わっています。5〜20秒の注文には、あります。 これがそれを意味する、buffersizeして、burstsizeする、同様のトランスミッション持続時間を持つように調整できました。
Polites, Wollman & Woo Experimental [Page 18] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[18ページ]RFC1986に言い寄ってください。
3. REFERENCE SECTION
3. 参照部
[1] Clark, D., Lambert, M., and L. Zhang,
"NETBLT: A Bulk Data Transfer Protocol", RFC 998, MIT,
March 1987.
[1] クラーク、D.、ランバート、M.、およびL.チャン、「NETBLT:」 「バルク・データ転送プロトコル」、RFC998、MIT、1987年3月。
[2] Postel, J., "User Datagram Protocol" STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[2] ポステル、J.、「ユーザー・データグラム・プロトコル」STD6、RFC768、科学が1980年8月に設けるUSC/情報。
[3] Sollins, K., "Trivial File Transfer Protocol", STD 33,
RFC 1350, MIT, July 1992.
[3]Sollins、K.、「トリビアル・ファイル転送プロトコル」、STD33、RFC1350、MIT、1992年7月。
[4] MIL-STD-2045-44500, 18 June 1993, "Military Standard Tactical
Communications Protocol 2 (TACO 2) fot the National Imagery
Transmission Format Standard", Ft. Monmouth, New Jersey.
[4] 軍規格2045-44500、1993年6月18日、「軍事のStandard Tactical Communicationsプロトコル2(TACO2)fot National Imagery Transmission Format Standard。」(Ft) モンマス(ニュージャージー)。
[5] Stevens, W. Richard, 1990, "UNIX Network Programming",
Prentice-Hall Inc., Englewood, New Jersey, Chapter 12.
[5] スティーブンス、W.リチャード、「UNIXネットワーク・プログラミング」、新米のホール株式会社、イングルウッド(ニュージャージー)、1990年の第12章。
[6] Lambert, M., "On Testing the NETBLT Protocol over
Divers Networks", RFC 1030, MIT, November 1987.
[6] ランバート、M. 「幾つかのネットワークの上でNETBLTプロトコルをテストする」ときのRFC1030、MIT、1987年11月。
4. SECURITY CONSIDERATIONS
4. セキュリティ問題
The ETFTP program is a security loophole in any UNIX environment. There is no user/password validation. All the problems associated to TFTP are repeated in ETFTP. The server program must be owned by root and setuid to root in order to work. As an experimental prototype program, the security issue was overlooked. Since this protocol has proven too be a viable solution in tactical radio networks, the security issues will have to be addressed, and corrected.
ETFTPプログラムはどんなunix環境でもセキュリティーの抜け道です。 ユーザ/パスワード合法化が全くありません。 TFTPに関連づけられたすべての問題がETFTPで繰り返されます。 根とsetuidは、働くために根づくためにサーバプログラムを所有しなければなりません。 実験用プロトタイププログラムとして、安全保障問題は見落とされました。 このプロトコルが、戦術のラジオ放送網における実行可能なソリューションであるようにまた、立証したので、安全保障問題は、扱われて、修正されなければならないでしょう。
Polites, Wollman & Woo Experimental [Page 19] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[19ページ]RFC1986に言い寄ってください。
5. AUTHORS' ADDRESSES
5. 作者のアドレス
William J. Polites The Mitre Corporation 145 Wyckoff Rd. Eatontown, NJ 07724
ウィリアムJ.Polites斜め継ぎ社145のワイコフ通り Eatontown、ニュージャージー 07724
Phone: (908) 544-1414 EMail:wpolites@mitre.org
以下に電話をしてください。 (908) 544-1414メール: wpolites@mitre.org
William Wollman The Mitre Corporation 145 Wyckoff Rd. Eatontown, NJ 07724
ウィリアム・ウォルマン斜め継ぎ社145のワイコフ通り Eatontown、ニュージャージー 07724
Phone: (908) 544-1414 EMail:wwollman@mitre.org
以下に電話をしてください。 (908) 544-1414メール: wwollman@mitre.org
David Woo The Mitre Corporation 145 Wyckoff Rd. Eatontown, NJ 07724
デヴィッドは斜め継ぎ社145のワイコフ通りに言い寄ります。 Eatontown、ニュージャージー 07724
Phone: (908) 544-1414 EMail: dwoo@mitre.org
以下に電話をしてください。 (908) 544-1414 メールしてください: dwoo@mitre.org
Russ Langan U.S. Army Communications Electronics Command (CECOM) AMSEL-RD-ST-SP ATTN: Russell Langan Fort Monmouth, NJ 07703
ラスランガン米軍コミュニケーションエレクトロニクスは(CECOM)AMSEL第SP ATTNを命令します: ラッセル・ランガン・Fortモンマス、ニュージャージー 07703
Phone: (908) 427-2064 Fax: (908) 427-2822 EMail: langanr@doim6.monmouth.army.mil
以下に電話をしてください。 (908) 427-2064 Fax: (908) 427-2822 メールしてください: langanr@doim6.monmouth.army.mil
Polites, Wollman & Woo Experimental [Page 20] RFC 1986 ETFTP August 1996
Polites、ウォルマン、ETFTP1996年8月に実験的な[20ページ]RFC1986に言い寄ってください。
6. GLOSSARY
6. 用語集
ATD Advanced Technology Demonstration AX.25 Amateur Radio X.25 Protocol BER Bit Error Rate EPLRS Enhanced Position Location Reporting Systems ETFTP Enhanced Trivial File Transfer Protocol FEC Forward Error Correction FTP File Transfer Protocol HF High Frequency LCU Lightweight Computer Unit ms milliseconds MTU Maximum Transfer Unit NETBLT NETwork Block Transfer protocol NITFS National Imagery Transmission Format Standard PC Personal Computer RNC Radio Network Controller SAS Survivable Adaptive Systems SATCOM SATellite COMmunications SCO Santa Cruz Operations SINCGARS SINgle Channel Ground and Airborne Radio Systems SLIP Serial Line Internet Protocol TACO2 Tactical Communications Protocol 2 TCP Transmission Control Protocol TFTP Trivial File Transfer Protocol UDP User Datagram Protocol UHF Ultra High Frequency
ATDは技術デモンストレーション斧.25のアマチュア無線Xを進めました; 25プロトコルBER Bit Error Rate EPLRS Enhanced Position Location Reporting Systems ETFTP Enhancedトリビアル・ファイル転送プロトコルFEC Forward Error Correction FTP File TransferプロトコルHF High Frequency LCUライト級コンピュータUnit msミリセカンドMTU Maximum Transfer Unit NETBLT NETwork Block TransferプロトコルNITFS National Imagery Transmission Format Standard PCパーソナル; サンタクルス操作SINCGARSが選抜するコンピュータRNCラジオ放送網コントローラSAS生存可能な適応型のシステムSATCOM衛星通信SCOは地面を向けます、そして、機上無線機システムはシリアル回線インターネット・プロトコルのTACO2の戦術の通信規約2TCP通信制御プロトコルTFTPトリビアル・ファイル転送プロトコルUDPユーザー・データグラム・プロトコルUHF極超短波を滑らせます。
* Modification from NETBLT RFC 998. * The new packet size is a modification to the NETBLT RFC 998. * The new packet size is a modification to the NETBLT RFC 998.
* NETBLT RFC998からの変更。 * 新しいパケットサイズはNETBLT RFC998への変更です。 * 新しいパケットサイズはNETBLT RFC998への変更です。
Polites, Wollman & Woo Experimental [Page 21]
Polites、ウォルマン、言い寄る、実験的[21ページ]
一覧
スポンサーリンク
