RFC2054 日本語訳
2054 WebNFS Client Specification. B. Callaghan. October 1996. (Format: TXT=36354 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Callaghan Request for Comments: 2054 Sun Microsystems, Inc. Category: Informational October 1996
コメントを求めるワーキンググループB.キャラハン要求をネットワークでつないでください: 2054年のサン・マイクロシステムズ・インクカテゴリ: 情報の1996年10月
WebNFS Client Specification
WebNFSクライアント仕様
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes a lightweight binding mechanism that allows NFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. In removing this overhead, WebNFS clients see benefits in faster response to requests, easy transit of packet filter firewalls and TCP-based proxies, and better server scalability.
このドキュメントはNFSクライアントが最小プロトコルオーバーヘッドでWebNFSによって可能にされたサーバからサービスを得ることができる軽量の結合機構について説明します。 このオーバーヘッドを取り除く際に、WebNFSクライアントは要求への、より速い応答、パケットフィルタファイアウォールの簡単なトランジット、TCPベースのプロキシ、および、より良いサーバスケーラビリティにおける利益を見ます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. TCP vs UDP . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Well-known Port . . . . . . . . . . . . . . . . . . . . . 2 4. NFS Version 3 . . . . . . . . . . . . . . . . . . . . . . 3 4.1 Transfer Size . . . . . . . . . . . . . . . . . . . . . 3 4.2 Fast Writes . . . . . . . . . . . . . . . . . . . . . . 4 4.3 READDIRPLUS . . . . . . . . . . . . . . . . . . . . . . 4 5. Public Filehandle . . . . . . . . . . . . . . . . . . . . 5 5.1 NFS Version 2 Public Filehandle . . . . . . . . . . . . 5 5.2 NFS Version 3 Public Filehandle . . . . . . . . . . . . 5 6. Multi-component Lookup . . . . . . . . . . . . . . . . . . 6 6.1 Canonical Path vs. Native Path . . . . . . . . . . . . . 6 6.2 Symbolic Links . . . . . . . . . . . . . . . . . . . . . 7 6.2.1 Absolute Link . . . . . . . . . . . . . . . . . . . . 8 6.2.2 Relative Link . . . . . . . . . . . . . . . . . . . . 8 6.3 Filesystem Spanning Pathnames . . . . . . . . . . . . . 9 7. Contacting the Server . . . . . . . . . . . . . . . . . . 9 8. Mount Protocol . . . . . . . . . . . . . . . . . . . . . . 11 9. Exploiting Concurrency . . . . . . . . . . . . . . . . . . 12 9.1 Read-ahead . . . . . . . . . . . . . . . . . . . . . . . 12 9.2 Concurrent File Download . . . . . . . . . . . . . . . . 13 10. Timeout and Retransmission . . . . . . . . . . . . . . . . 13 11. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . 16
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 2。 TCP対UDP. . . . . . . . . . . . . . . . . . . . . . . . 2 3 ウェルノウンポート. . . . . . . . . . . . . . . . . . . . . 2 4。 NFSバージョン3.34.1転送サイズ. . . . . . . . . . . . . . . . . . . . . 3 4.2は速く.44.3READDIRPLUS. . . . . . . . . . . . . . . . . . . . . . 4 5に書きます。 公共のFilehandle. . . . . . . . . . . . . . . . . . . . 5 5.1NFSバージョン2の公共のFilehandle. . . . . . . . . . . . 5 5.2NFSバージョン3の公共のFilehandle. . . . . . . . . . . . 5 6。 多成分系のルックアップ.66.1正準な経路対パス名. . . . . . . . . . . . . 9 7にかかる経路.66.2の固有のシンボリックリンク. . . . . . . . . . . . . . . . . . . . . 7 6.2.1の絶対リンク. . . . . . . . . . . . . . . . . . . . 8 6.2.2の相対的なリンク. . . . . . . . . . . . . . . . . . . . 8 6.3ファイルシステム サーバ. . . . . . . . . . . . . . . . . . 9 8に連絡します。 プロトコル. . . . . . . . . . . . . . . . . . . . . . 11 9を取り付けてください。 並行性. . . . . . . . . . . . . . . . . . 12 9.1を利用すると、-先では、.129.2の同時発生のファイルダウンロード. . . . . . . . . . . . . . . . 13 10は読まれました。 タイムアウトとRetransmission. . . . . . . . . . . . . . . . 13 11。 図書目録. . . . . . . . . . . . . . . . . . . . . . . 15 12。 セキュリティ問題. . . . . . . . . . . . . . . . . 16
Callaghan Informational [Page 1] RFC 2054 WebNFS Client Specification October 1996
[1ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 16 14. Author's Address . . . . . . . . . . . . . . . . . . . . . 16
13. 承認. . . . . . . . . . . . . . . . . . . . . 16 14。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
The NFS protocol provides access to shared filesystems across networks. It is designed to be machine, operating system, network architecture, and transport protocol independent. The protocol currently exists in two versions: version 2 [RFC1094] and version 3 [RFC1813], both built on Sun RPC [RFC1831] at its associated eXternal Data Representation (XDR) [RFC1832] and Binding Protocol [RFC1833].
NFSプロトコルはネットワークの向こう側に共有されたファイルシステムへのアクセスを提供します。 それは、マシン、オペレーティングシステム、ネットワークアーキテクチャ、およびトランスポート・プロトコルから独立しているように設計されています。 プロトコルは現在、2つのバージョンに存在します: バージョン2[RFC1094]とバージョン3 [RFC1813]、両方がその関連eXternal Data Representation(XDR)[RFC1832]とBindingプロトコル[RFC1833]におけるSun RPC[RFC1831]に建てられました。
WebNFS provides additional semantics that can be applied to NFS version 2 and 3 to eliminate the overhead of PORTMAP and MOUNT protocols, make the protocol easier to use where firewall transit is required, and reduce the number of LOOKUP requests required to identify a particular file on the server. WebNFS server requirements are described in RFC 2055.
WebNFSはPORTMAPのオーバーヘッドと山のプロトコルを取り除いて、ファイアウォールトランジットが必要であるところでプロトコルを使用するのをより簡単にして、要求がサーバの特定のファイルを特定するのを必要としたLOOKUPの数を減少させるためにNFSバージョン2と3に適用できる追加意味論を提供します。WebNFSサーバ要件はRFC2055で説明されます。
2. TCP vs UDP
2. TCP対UDP
The NFS protocol is most well known for its use of UDP which performs acceptably on local area networks. However, on wide area networks with error prone, high-latency connections and bandwidth contention, TCP is well respected for its congestion control and superior error handling. A growing number of NFS implementations now support the NFS protocol over TCP connections.
ローカル・エリア・ネットワークに許容できて働くUDPの使用において、NFSプロトコルは最もよく知られています。 しかしながら、誤りは傾向がある広域ネットワーク、高潜在接続、および帯域幅主張のときに、TCPはその輻輳制御と優れたエラー処理のためによく尊敬されます。 増加している数のNFS実装が現在、TCP接続の上でNFSプロトコルをサポートします。
Use of NFS version 3 is particularly well matched to the use of TCP as a transport protocol. Version 3 removes the arbitrary 8k transfer size limit of version 2, allowing the READ or WRITE of very large streams of data over a TCP connection. Note that NFS version 2 is also supported on TCP connections, though the benefits of TCP data streaming will not be as great.
NFSバージョン3の使用はトランスポート・プロトコルとして特にTCPの使用によく合われています。 バージョン3はバージョン2の任意の8k転送サイズ限界を取り除きます、TCP接続の上にデータの非常に大きいストリームのREADかWRITEを許容して。 また、NFSバージョン2がTCP接続のときにサポートされることに注意してください、TCPデータストリーミングの利益は同じくらいすばらしくないでしょうが。
A WebNFS client must first attempt to connect to its server with a TCP connection. If the server refuses the connection, the client should attempt to use UDP.
WebNFSクライアントは、最初に、TCP接続と共にサーバに接続するのを試みなければなりません。 サーバが接続を拒否するなら、クライアントは、UDPを使用するのを試みるべきです。
3. Well-known Port
3. ウェルノウンポート
While Internet protocols are generally identified by registered port number assignments, RPC based protocols register a 32 bit program number and a dynamically assigned port with the portmap service which is registered on the well-known port 111. Since the NFS protocol is RPC-based, NFS servers register their port assignment with the portmap service.
一般に、インターネットプロトコルが登録されたポートナンバー課題で特定されている間、RPCのベースのプロトコルは32ビットのプログラム番号とダイナミックに割り当てられたポートをウェルノウンポート111に登録されるportmapサービスに示します。 NFSプロトコルがRPCベースであるので、NFSサーバは彼らのポート課題をportmapサービスに登録します。
Callaghan Informational [Page 2] RFC 2054 WebNFS Client Specification October 1996
[2ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
NFS servers are constrained by a requirement to re-register at the same port after a server crash and recovery so that clients can recover simply by retransmitting an RPC request until a response is received. This is simpler than the alternative of having the client repeatedly check with the portmap service for a new port assignment. NFS servers typically achieve this port invariance by registering a constant port assignment, 2049, for both UDP and TCP.
クライアントが単に応答が受け取られているまでRPC要求を再送することによって回復できるようにサーバクラッシュと回復の後に同じポートに再登録するという要件によってNFSサーバは抑制されます。 これはクライアントに繰り返して新しいポート課題のためのportmapサービスに問い合わせさせる代替手段より簡単です。 NFSサーバは、UDPとTCPの両方のために一定のポート課題、2049を登録することによって、このポートの不変性を通常実現します。
To avoid the overhead of contacting the server's portmap service, and to facilitate transit through packet filtering firewalls, WebNFS clients optimistically assume that WebNFS servers register on port 2049. Most NFS servers use this port assignment already, so this client optimism is well justified. Refer to section 8 for further details on port binding.
サーバのportmapサービスに連絡するオーバーヘッドを避けて、パケットフィルタリングファイアウォールを通したトランジットを容易にするために、WebNFSクライアントは、WebNFSサーバがポート2049の上に登録されると楽観的に仮定します。 ほとんどのNFSサーバが既にこのポート課題を使用するので、このクライアント楽観主義はよく正当化されます。 さらに詳しい明細についてはポート結合のときにセクション8を参照してください。
4. NFS Version 3
4. NFSバージョン3
NFS version 3 corrects deficiencies in version 2 of the protocol as well as providing a number of features suitable to WebNFS clients accessing servers over high-latency, low-bandwidth connections.
NFSバージョン3はWebNFSクライアントにとって、適当な多くの特徴を提供することと同様にプロトコルが高い潜在、低バンド幅接続の上でサーバにアクセスするバージョン2の欠乏を修正します。
4.1 Transfer Size
4.1 転送サイズ
NFS version 2 limited the amount of data in a single request or reply to 8 kilobytes. This limit was based on what was then considered a reasonable upper bound on the amount of data that could be transmitted in a UDP datagram across an Ethernet. The 8k transfer size limitation affects READ, WRITE, and READDIR requests. When using version 2, a WebNFS client must not transmit any request that exceeds the 8k transfer size. Additionally, the client must be able to adjust its requests to suit servers that limit transfer sizes to values smaller than 8k.
NFSバージョン2は、ただ一つの要求におけるデータ量を制限するか、または8キロバイトに答えます。 この限界は次に、何がイーサネットの向こう側にUDPデータグラムで伝えることができたデータ量に関する妥当な上限であると考えられたかに基づきました。 8k転送サイズ制限はREAD、WRITE、およびREADDIR要求に影響します。 バージョン2を使用するとき、WebNFSクライアントは8k転送サイズを超えているどんな要求も伝えてはいけません。 さらに、クライアントは転送サイズを8kより小さい値に制限するサーバに合うという要求を調整できなければなりません。
NFS version 3 removes the 8k limit, allowing the client and server to negotiate whatever limit they choose. Larger transfer sizes are preferred since they require fewer READ or WRITE requests to transfer a given amount of data and utilize a TCP stream more efficiently.
クライアントとサーバが彼らが選ぶどんな限界も交渉するのを許容して、NFSバージョン3は8k限界を取り除きます。 彼らが、より少ないREADか与えられた量のデータを移して、より効率的にTCPストリームを利用するというWRITE要求を必要として、より大きい転送サイズは好まれます。
While the client can use the FSINFO procedure to request the server's maximum and preferred transfer sizes, in the interests of keeping the number of NFS requests to a minimum, WebNFS clients should optimistically choose a transfer size and make corrections if necessary based on the server's response.
クライアントがサーバの最大の、そして、都合のよい転送サイズを要求するのにFSINFO手順を用いることができる間、NFS要求の数を最小に抑えることのために、WebNFSクライアントは、楽観的に転送サイズを選んで、必要なら、サーバの応答に基づく修正をするべきです。
For instance, given that the file attributes returned with the filehandle from a LOOKUP request indicate that the file has a size of 50k, the client might transmit a READ request for 50k. If the server returns only 32k, then the client can assume that the server's
例えば、filehandleでLOOKUP要求から返されたファイル属性が、ファイルには50kのサイズがあるのを示すなら、クライアントが50kを求めるREAD要求を伝えるかもしれません。 サーバが32kだけを返すなら、クライアントは、それがサーバのものであると仮定できます。
Callaghan Informational [Page 3] RFC 2054 WebNFS Client Specification October 1996
[3ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
maximum transfer size is 32k and issue another read request for the remaining data. The server will indicate positively when the end of file is reached.
最大の転送サイズは、32kと別のものが残りのためにデータを要求すると読む問題です。 サーバは、ファイルの終りにいつ達しているかを明確に示すでしょう。
A similar strategy can be used when writing to a file on the server, though the client should be more conservative in choosing write request sizes so as to avoid transmitting large amounts of data that the server cannot handle.
サーバのファイルに書くとき、同様の戦略を使用できて、選ぶことではクライアントは、より保守的であるべきですが、サーバが扱うことができない多量のデータを送るのを避けるために要求サイズを書いてください。
4.2 Fast Writes
4.2速く、書きます。
NFS version 2 requires the server to write client data to stable storage before responding to the client. This avoids the possibility of the the server crashing and losing the client's data after a positive response. While this requirement protects the client from data loss, it requires that the server direct client write requests directly to the disk, or to buffer client data in expensive non- volatile memory (NVRAM). Either way, the effect is poor write performance, either through inefficient synchronous writes to the disk or through the limited buffering available in NVRAM.
NFSバージョン2は、クライアントに応じる前にクライアントデータを安定貯蔵まで書くためにサーバを必要とします。 これはサーバが積極的な応答の後にクライアントのデータを墜落して、失う可能性を避けます。 この要件はデータの損失からクライアントを保護しますが、それは、サーバのダイレクトクライアントが直接ディスク、または、高価な非揮発性メモリーの(NVRAM)のバッファクライアントデータに要求を書くのを必要とします。 いずれにせよ、効果は貧乏人が効率の悪いことを通して同時の状態で性能を書くということです。ディスクか制限を通してNVRAMで利用可能なバッファリングを書きます。
NFS version 3 provides clients with the option of having the server buffer a series of WRITE requests in unstable storage. A subsequent COMMIT request from the client will have the server flush the data to stable storage and have the client verify that the server lost none of the data. Since fast writes benefit both the client and the server, WebNFS clients should use WRITE/COMMIT when writing to the server.
NFSバージョン3は不安定なストレージにおける一連のWRITE要求をサーババッファを持つオプションのクライアントに提供します。 サーバでデータを安定貯蔵に洗い流して、クライアントが、サーバがデータのいずれも失わなかったことを確かめるのをクライアントからのその後のCOMMIT要求は、させるでしょう。 以来サーバに書くとき、速く利益の両方にクライアントを書いて、サーバ、クライアントが使用するべきであるWebNFSにWRITE/COMMITを書きます。
4.3 READDIRPLUS
4.3 READDIRPLUS
The NFS version 2 READDIR procedure is also supported in version 3. READDIR returns the names of the entries in a directory along with their fileids. Browser programs that display directory contents as a list will usually display more than just the filename; a different icon may be displayed if the entry is a directory or a file. Similarly, the browser may display the file size, and date of last modification.
また、NFSバージョン2READDIR手順はバージョン3でサポートされます。 READDIRはそれらのfileidsに伴うディレクトリにおけるエントリーの名前を返します。 通常、リストとしてディレクトリコンテンツを表示するブラウザのプログラムがまさしくファイル名よりもう少し表示するでしょう。 エントリーがディレクトリかファイルであるなら異なったアイコンを表示するかもしれません。 同様に、ブラウザはファイルサイズ、および最終変更日付を表示するかもしれません。
Since this additional information is not returned by READDIR, version 2 clients must issue a series of LOOKUP requests, one per directory member, to retrieve the attribute data. Clearly this is an expensive operation where the directory is large (perhaps several hundred entries) and the network latency is high.
この追加情報がREADDIRによって返されないので、バージョン2クライアントは属性データを検索するために一連のLOOKUP要求、ディレクトリメンバーあたり1つを発行しなければなりません。 そして、明確に、これがディレクトリが大きいところの高価な操作である、(恐らく、数100のエントリー)、ネットワーク潜在は高いです。
The version 3 READDIRPLUS request allows the client to retrieve not only the names of the directory entries, but also their file attributes and filehandles in a single call. WebNFS clients that
READDIRPLUSが要求するバージョン3で、クライアントはただ一つの呼び出しでディレクトリエントリーの名前だけではなく、それらのファイル属性とfilehandlesも検索できます。 WebNFSクライアント、それ
Callaghan Informational [Page 4] RFC 2054 WebNFS Client Specification October 1996
[4ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
require attribute information for directory entries should use READDIRPLUS in preference to READDIR.
ディレクトリのためのエントリーがREADDIRに優先してREADDIRPLUSを使用するべきであるという属性情報を必要としてください。
5. Public Filehandle
5. 公共のFilehandle
NFS filehandles are normally created by the server and used to identify uniquely a particular file or directory on the server. The client does not normally create filehandles or have any knowledge of the contents of a filehandle.
NFS filehandlesは、唯一サーバの特定のファイルかディレクトリを特定するのに通常、サーバによって作成されて、使用されます。クライアントには、通常、filehandlesを作成しないか、またはfilehandleのコンテンツに関する少しの知識もありません。
The public filehandle is an an exception. It is an NFS filehandle with a reserved value and special semantics that allow an initial filehandle to be obtained. A WebNFS client can use the public filehandle as an initial filehandle rather than using the MOUNT protocol. Since NFS version 2 and version 3 have different filehandle formats, the public filehandle is defined differently for each.
公共のfilehandleがそうである、例外。 初期のfilehandleが入手されるのを許容するのは、予約された値と特別な意味論があるNFS filehandleです。 WebNFSクライアントは山のプロトコルを使用するより初期のfilehandleとしてむしろ公共のfilehandleを使用できます。 NFSバージョン2とバージョン3には異なったfilehandle形式があるので、公共のfilehandleはそれぞれのために異なって定義されます。
The public filehandle is a zero filehandle. For NFS version 2 this is a filehandle with 32 zero octets. A version 3 public filehandle has zero length.
公共のfilehandleはfilehandleにaゼロです。 NFSバージョン2のために、32があるfilehandleは八重奏のゼロに合っています。 バージョン3の公共のfilehandleには、ゼロ・レングスがあります。
5.1 NFS Version 2 Public Filehandle
5.1 NFSバージョン2の公共のFilehandle
A version 2 filehandle is defined in RFC 1094 as an opaque value occupying 32 octets. A version 2 public filehandle has a zero in each octet, i.e. all zeros.
バージョン2filehandleはRFC1094で32の八重奏を占領する不透明な値と定義されます。 バージョン2の公共のfilehandleはすなわち、各八重奏、すべてのゼロでゼロを持っています。
1 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2 NFS Version 3 Public Filehandle
5.2 NFSバージョン3の公共のFilehandle
A version 3 filehandle is defined in RFC 1813 as a variable length opaque value occupying up to 64 octets. The length of the filehandle is indicated by an integer value contained in a 4 octet value which describes the number of valid octets that follow. A version 3 public filehandle has a length of zero.
バージョン3filehandleはRFC1813で最大64の八重奏を占領する可変長の不透明な値と定義されます。 filehandleの長さは続く有効な八重奏の数について説明する4八重奏価値に含まれた整数値によって示されます。 バージョン3の公共のfilehandleには、ゼロの長さがあります。
+-+-+-+-+ | 0 | +-+-+-+-+
+-+-+-+-+ | 0 | +-+-+-+-+
Callaghan Informational [Page 5] RFC 2054 WebNFS Client Specification October 1996
[5ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
6. Multi-component Lookup
6. 多成分系のルックアップ
Normally the NFS LOOKUP request (version 2 or 3) takes a directory filehandle along with the name of a directory member, and returns the filehandle of the directory member. If a client needs to evaluate a pathname that contains a sequence of components, then beginning with the directory filehandle of the first component it must issue a series of LOOKUP requests one component at a time. For instance, evaluation of the Unix path "a/b/c" will generate separate LOOKUP requests for each component of the pathname "a", "b", and "c".
通常、NFS LOOKUPは、(バージョン2か3)がディレクトリメンバーの名前に伴うディレクトリfilehandleを取って、ディレクトリメンバーのfilehandleを返すよう要求します。 クライアントが、コンポーネントの系列を含むパス名を評価する必要があるなら、最初のコンポーネントのディレクトリfilehandleでそれを始めると、一連のLOOKUP要求が一度に1つのコンポーネントに出されなければなりません。 例えば、「/b/c」が別々のLOOKUPを生成するUnix経路の評価はパス名の各成分のために“a"、「b」、および「c」を要求します。
A LOOKUP request that uses the public filehandle can provide a pathname containing multiple components. The server is expected to evaluate the entire pathname and return a filehandle for the final component. Both canonical (slash-separated) and server native pathnames are supported.
公共のfilehandleを使用するLOOKUP要求は複数のコンポーネントを含むパス名を提供できます。 サーバは、全体のパス名を評価して、最終的なコンポーネントのためにfilehandleを返すと予想されます。 ともに正準(スラッシュで切り離された)とサーバの固有のパス名はサポートされます。
For example, rather than evaluate the path "a/b/c" as:
例えば、そして、むしろ、経路を評価する、以下としての「a/b/c」
LOOKUP FH=0x0 "a" --->
<--- FH=0x1
LOOKUP FH=0x1 "b" --->
<--- FH=0x2
LOOKUP FH=0x2 "c" --->
<--- FH=0x3
ルックアップFH=0x0“a"---><。--- FH=0x1ルックアップFH=0x1「b」---><。--- FH=0x2ルックアップFH=0x2「c」---><。--- FH=0x3
Relative to the public filehandle these three LOOKUP requests can be replaced by a single multi-component lookup:
公共のfilehandleに比例して、これらの3つのLOOKUP要求をただ一つの多成分系のルックアップに取り替えることができます:
LOOKUP FH=0x0 "a/b/c" --->
<--- FH=0x3
「/b/c」あたりのルックアップFH=0×0---><。--- FH=0x3
Multi-component lookup is supported only for LOOKUP requests relative to the public filehandle.
多成分系のルックアップはLOOKUP要求のためだけに公共のfilehandleに比例してサポートされます。
6.1 Canonical Path vs. Native Path
6.1 正準な経路対ネイティブの経路
If the pathname in a multi-component LOOKUP request begins with an ASCII character, then it must be a canonical path. A canonical path is a hierarchically-related, slash-separated sequence of components, <directory>/<directory>/.../<name>. Occurrences of the "/" character within a component must be escaped using the escape code %2f. Non- ascii characters within components must also be escaped using the "%" character to introduce a two digit hexadecimal code. Occurrences of the "%" character that do not introduce an encoded character must themselves be encoded with %25.
多成分系のLOOKUP要求におけるパス名がASCII文字と共に始まるなら、それは正準な経路であるに違いありません。 正準な経路がaである、階層的である、関連、コンポーネントのスラッシュで切り離された系列、<ディレクトリ>/<ディレクトリ>/…/<名前>。 「発生、」 」 コンポーネントの中のキャラクタが逃げられた使用がエスケープコード%2fであったならそうしなければならない/。 また、2ケタ16進コードを紹介するのに「%」キャラクタを使用することでコンポーネントの中の非ASCIIのキャラクタから逃げなければなりません。 そうする「%」キャラクタの発生は自分たちでコード化されたキャラクタ必須を導入しません。%25で、コード化されます。
Callaghan Informational [Page 6] RFC 2054 WebNFS Client Specification October 1996
[6ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
If the first character of the path is a slash, then the canonical path will be evaluated relative to the server's root directory. If the first character is not a slash, then the path will be evaluated relative to the directory with which the public filehandle is associated.
経路の最初のキャラクタがそうなら、スラッシュであり、そして、正準な経路はサーバのルートディレクトリに比例して評価されるでしょう。 最初のキャラクタがスラッシュでないなら、経路は公共のfilehandleが関連しているディレクトリに比例して評価されるでしょう。
Not all WebNFS servers can support arbitrary use of absolute paths. Clearly, the server cannot return a filehandle if the path identifies a file or directory that is not exported by the server. In addition, some servers will not return a filehandle if the path names a file or directory in an exported filesystem different from the one that is associated with the public filehandle.
すべてのWebNFSサーバが絶対パスの任意の使用をサポートすることができるというわけではありません。 明確に、経路がサーバによってエクスポートされないファイルかディレクトリを特定するなら、サーバはfilehandleを返すことができません。さらに、いくつかのサーバは公共のfilehandleに関連しているものと異なったエクスポートしているファイルシステムでaがパス名であるならfilehandleするどんなリターンにもファイルかディレクトリを望んでいません。
If the first character of the path is 0x80 (non-ascii) then the following character is the first in a native path. A native path conforms to the normal pathname syntax of the server. For example:
経路の最初のキャラクタが0×80(非ASCII)であるなら、以下のキャラクタはネイティブの経路で1番目です。 ネイティブの経路がサーバの正常なパス名構文に従う、例えば:
Lookup for Canonical Path:
正準な経路へのルックアップ:
LOOKUP FH=0x0 "/a/b/c"
ルックアップFH=0x0"/a/b/c"
Lookup for Native Path:
ネイティブの経路へのルックアップ:
LOOKUP FH=0x0 0x80 "a:b:c"
ルックアップFH=0x0 0x80「a:b:c」
6.2 Symbolic Links
6.2のシンボリックリンク
On Unix servers, components within a pathname may be symbolic links. The server will evaluate these symbolic links as a part of the normal pathname evaluation process. If the final component is a symbolic link, the server will return its filehandle, rather than evaluate it.
Unixサーバーでは、パス名の中のコンポーネントはシンボリックリンクであるかもしれません。 サーバは正常なパス名評価プロセスの一部としてこれらのシンボリックリンクを評価するでしょう。 最終的なコンポーネントがシンボリックリンクであるなら、サーバはそれを評価するよりむしろfilehandleを返すでしょう。
If the attributes returned with a filehandle indicate that it refers to a symbolic link, then it is the client's responsibility to deal with the link by fetching the contents of the link using the READLINK procedure. What follows is determined by the contents of the link.
filehandleで返された属性が、シンボリックリンクを示すのを示すなら、READLINK手順を用いることでリンクのコンテンツをとって来ることによってリンクに対処するのは、クライアントの責任です。 続くことはリンクのコンテンツで決定します。
Evaluation of symbolic links by the client is defined only if the symbolic link is retrieved via the multi-component lookup of a canonical path.
シンボリックリンクが正準な経路の多成分系のルックアップで検索される場合にだけ、クライアントによるシンボリックリンクの評価は定義されます。
Callaghan Informational [Page 7] RFC 2054 WebNFS Client Specification October 1996
[7ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
6.2.1 Absolute Link
6.2.1 絶対リンク
If the first character of the link text is a slash "/", then the following path can be assumed to be absolute. The entire path must be evaluated by the server relative to the public filehandle:
「」 リンクテキストの最初のキャラクタであるなら、スラッシュは/である」(絶対であると以下の経路を思うことができるその時)? サーバで公共のfilehandleに比例して全体の経路を評価しなければなりません:
LOOKUP FH=0x0 "a/b" --->
<--- FH=0x1 (symbolic link)
READLINK FH=0x1 --->
<--- "/x/y"
LOOKUP FH=0x0 "/x/y"
<--- FH=0x2
「/b」あたりのルックアップFH=0×0---><。--- FH=0x1(シンボリックリンク)READLINK FH=0x1---><。--- "/x/y"ルックアップFHは0×0"/x/y"<と等しいです。--- FH=0x2
So in this case the client just passes the link text back to the server for evaluation.
それで、この場合、クライアントはただリンクテキストを評価のためのサーバに戻します。
6.2.2 Relative Link
6.2.2 相対的なリンク
If the first character of the link text is not a slash, then the following path can be assumed to be relative to the location of the symbolic link. To evaluate this correctly, the client must substitute the link text in place of the final pathname component that named the link and issue a another LOOKUP relative to the public filehandle.
リンクテキストの最初のキャラクタがスラッシュでないなら、以下の経路がシンボリックリンクの位置に比例していると思うことができます。 正しくこれを評価するために、クライアントは公共のfilehandleに比例してリンクと問題を別のLOOKUPと命名した最終的なパス名コンポーネントに代わってリンクテキストを代入しなければなりません。
LOOKUP FH=0x0 "a/b" --->
<--- FH=0x1 (symbolic link)
READLINK FH=0x1 --->
<--- "x/y"
LOOKUP FH=0x0 "a/x/y"
<--- FH=0x2
「/b」あたりのルックアップFH=0×0---><。--- FH=0x1(シンボリックリンク)READLINK FH=0x1---><。--- 「x/y」ルックアップFHは0×0「/x/y」<と等しいです。--- FH=0x2
By substituting the link text in the link path and having the server evaluate the new path, the server effectively gets to evaluate the link relative to the link's location.
リンク経路でリンクテキストを代入して、サーバに新しい経路を評価させることによって、事実上、サーバは、リンクの位置に比例してリンクを評価し始めます。
The client may also "clean up" the resulting pathname by removing redundant components as described in Section 4. of RFC 1808.
また、クライアントは、RFC1808のセクション4で説明されるように余分なコンポーネントを取り除くことによって、結果として起こるパス名を「きれいにするかもしれません」。
Callaghan Informational [Page 8] RFC 2054 WebNFS Client Specification October 1996
[8ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
6.3 Filesystem Spanning Pathnames
6.3 ファイルシステムわたるパス名
NFS LOOKUP requests normally do not cross from one filesystem to another on the server. For instance if the server has the following export and mounts:
サーバで1つのファイルシステムから別のファイルシステムまで交差しないでください。NFS LOOKUPは通常、例えば、サーバに以下があるならエクスポートするよう要求して、上がります:
/export (exported)
/輸出(エクスポートされます)
/export/bigdata (mountpoint)
/export/bigdata(取付け位置)
then an NFS LOOKUP for "bigdata" using the filehandle for "/export" will return a "no file" error because the LOOKUP request did not cross the mountpoint on the server. There is a practical reason for this limitation: if the server permitted the mountpoint crossing to occur, then a Unix client might receive ambiguous fileid information inconsistent with it's view of a single remote mount for "/export". It is expected that the client resolve this by mirroring the additional server mount, e.g.
LOOKUP要求がサーバに関する取付け位置に交差しなかったので、「そして、」 /輸出にfilehandleを使用する"bigdata"のためのNFS LOOKUP」意志は「ファイルがありません」誤りを返します。この制限の実際的な理由があります: 「サーバが起こるように交差する取付け位置を可能にするなら、Unixクライアントは」 /輸出のためにそれに矛盾したあいまいなfileid情報の単一のリモートマウントに関する意見を受け取るでしょうに。」 クライアントが追加サーバマウントを映すことによってこれを決議すると例えば予想されます。
Client Server
クライアントサーバ
/mnt <--- mounted on --- /export
/mnt<。--- 取り付けられます。--- /輸出
/mnt/bigdata <--- mounted on --- /export/bigdata
/mnt/bigdata<。--- 取り付けられます。--- /export/bigdata
However, this semantic changes if the client issues the filesystem spanning LOOKUP relative to the public filehandle. If the following filesystems are exported:
しかしながら、この意味変化はクライアントであるなら公共のfilehandleに比例してLOOKUPにかかるファイルシステムを発行します。 以下のファイルシステムがエクスポートされるなら:
/export (exported public)
/輸出(エクスポートしている公衆)
/export/bigdata (exported mountpoint)
/export/bigdata(エクスポートしている取付け位置)
then an NFS LOOKUP for "bigdata" relative to the public filehandle will cross the mountpoint - just as if the client had issued a MOUNT request - but only if the new filesystem is exported, and only if the server supports Export Spanning Pathnames described in Section 6.3 of RFC 2055 [RFC2055].
そして、エクスポートされて、サーバが説明されたExport Spanning Pathnamesをサポートする場合にだけ新しいファイルシステムが交差している場合にだけ、まるでまさしくクライアントが山の要求を出したかのように公共のfilehandleに比例した"bigdata"のためのNFS LOOKUPはRFC2055[RFC2055]のセクション6.3で取付け位置に交差するでしょう。
7. Contacting the Server
7. サーバに連絡します。
WebNFS clients should be optimistic in assuming that the server supports WebNFS, but should be capable of fallback to conventional methods for server access if the server does not support WebNFS.
WebNFSクライアントは、サーバがWebNFSをサポートすると仮定するのにおいて楽観的であるべきですが、サーバがWebNFSをサポートしないなら、後退がサーバアクセスのための従来のメソッドにできるべきです。
Callaghan Informational [Page 9] RFC 2054 WebNFS Client Specification October 1996
[9ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
The client should start with the assumption that the server supports:
クライアントはサーバがサポートする仮定から始まるべきです:
- NFS version 3.
- NFSバージョン3。
- NFS TCP connections.
- NFS TCP接続。
- Public Filehandles.
- 公共のFilehandles。
If these assumptions are not met, the client should fall back gracefully with a minimum number of messages. The following steps are recommended:
これらの仮定が迎えられないなら、クライアントは最小の数のメッセージと共に優雅に後ろへ下がるべきです。 以下のステップはお勧めです:
1. Attempt to create a TCP connection to the server's
port 2049.
1. サーバのポート2049にTCP接続を創造するのを試みてください。
If the connection fails then assume that a request
sent over UDP will work. Use UDP port 2049.
接続が失敗するなら、UDPの上に送られた要求が働くと仮定してください。 UDPポート2049を使用してください。
Do not use the PORTMAP protocol to determine the
server's port unless the server does not respond to
port 2049 for both TCP and UDP.
サーバがTCPとUDPの両方のために2049を移植するために反応するなら、サーバのポートを決定するのにPORTMAPプロトコルを使用しないでください。
2. Assume WebNFS and V3 are supported.
Send an NFS version 3 LOOKUP with the public filehandle
for the requested pathname.
2. WebNFSとV3がサポートされると仮定してください。 要求されたパス名のために公共のfilehandleとNFSバージョン3LOOKUPを送ってください。
If the server returns an RPC PROG_MISMATCH error then
assume that NFS version 3 is not supported. Retry
the LOOKUP with an NFS version 2 public filehandle.
サーバがRPC PROG_MISMATCH誤りを返すなら、NFSバージョン3がサポートされないと仮定してください。 NFSバージョン2の公共のfilehandleでLOOKUPを再試行してください。
Note: The first call may not necessarily be a LOOKUP
if the operation is directed at the public filehandle
itself, e.g. a READDIR or READDIRPLUS of the directory
that is associated with the public filehandle.
以下に注意してください。 例えばディレクトリの公共のfilehandleに関連している公共のfilehandle自身、READDIRまたはREADDIRPLUSが操作に向けられるなら、準備ラッパは必ずLOOKUPであるかもしれないというわけではありません。
If the server returns an NFS3ERR_STALE, NFS3ERR_INVAL, or
NFS3ERR_BADHANDLE error, then assume that the server does
not support WebNFS since it does not recognize the public
filehandle. The client must use the server's portmap
service to locate and use the MOUNT protocol to obtain an
initial filehandle for the requested path.
サーバがNFS3ERR_STALE、NFS3ERR_INVAL、またはNFS3ERR_BADHANDLEに誤りを返すなら、公共のfilehandleを認識しないのでサーバがWebNFSをサポートしないと仮定してください。 クライアントは、初期のfilehandleを要求された経路に入手するのに山のプロトコルを場所を見つけて、使用するのにサーバのportmapサービスを利用しなければなりません。
WebNFS clients can benefit by caching information about the server: whether the server supports TCP connections (if TCP is supported then the client should cache the TCP connection as well), which protocol the server supports and whether the server supports public filehandles. If the server does not support public filehandles, the client may choose to cache the port assignment of the MOUNT service
WebNFSクライアントはサーバの情報をキャッシュすることによって、利益を得ることができます: サーバはTCP接続をサポートするかどうか、そして、(TCPがサポートされるなら、クライアントはまた、TCP接続をキャッシュするべきです)サーバはどのプロトコルをサポートするか、そして、サーバは公共のfilehandlesをサポートであるかどうか サーバが公共のfilehandlesをサポートしないなら、クライアントは、山のサービスのポート課題をキャッシュするのを選ぶかもしれません。
Callaghan Informational [Page 10] RFC 2054 WebNFS Client Specification October 1996
[10ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
as well as previously used pathnames and their filehandles.
以前中古のパス名とそれらのfilehandlesと同様に。
8. Mount Protocol
8. 山のProtocol
If the server returns an error to the client that indicates no support for public filehandles, the client must use the MOUNT protocol to convert the given pathname to a filehandle. Version 1 of the MOUNT protocol is described in Appendix A of RFC 1094 and version 3 in Appendix I of RFC 1813. Version 2 of the MOUNT protocol is identical to version 1 except for the addition of a procedure MOUNTPROC_PATHCONF which returns POSIX pathconf information from the server.
サーバが公共のfilehandlesのサポートを全く示さないクライアントに誤りを返すなら、クライアントは、与えられたパス名をfilehandleに変換するのに山のプロトコルを使用しなければなりません。 山のプロトコルのバージョン1はRFC1813のAppendix IでRFC1094とバージョン3のAppendix Aで説明されます。 山のプロトコルのバージョン2は情報をサーバからPOSIX pathconfに返す手順MOUNTPROC_PATHCONFの追加以外のバージョン1と同じです。
At this point the client must already have some indication as to which version of the NFS protocol is supported on the server. Since the filehandle format differs between NFS versions 2 and 3, the client must select the appropriate version of the MOUNT protocol. MOUNT versions 1 and 2 return only NFS version 2 filehandles, whereas MOUNT version 3 returns NFS version 3 filehandles.
ここに、クライアントには、NFSプロトコルのバージョンがサーバでサポートされる何らかの指示が既になければなりません。filehandle形式がNFSバージョン2と3の間で異なるので、クライアントは山のプロトコルの適切なバージョンを選択しなければなりません。 山のバージョン1と2はNFSバージョン2filehandlesだけを返しますが、山のバージョン3はNFSバージョン3filehandlesを返します。
Unlike the NFS service, the MOUNT service is not registered on a well-known port. The client must use the PORTMAP service to locate the server's MOUNT port before it can transmit a MOUNTPROC_MNT request to retrieve the filehandle corresponding to the requested path.
NFSサービスと異なって、山のサービスはウェルノウンポートに登録されません。 クライアントは、MNTが要求された経路に対応するfilehandleを検索するよう要求するMOUNTPROC_を伝えることができる前にサーバの山の港の場所を見つけるのにPORTMAPサービスを利用しなければなりません。
Client Server
------ ------
クライアントサーバ------ ------
-------------- MOUNT port ? --------------> Portmapper
<-------------- Port=984 ------------------
-------------- 山の港? -------------->ポートマッパー<。-------------- ポート=984------------------
------- Filehandle for /export/foo ? ----> Mountd @ port 984
<--------- Filehandle=0xf82455ce0.. ------
------- /export/fooのためのFilehandle? ---->Mountd@ポート984<。--------- Filehandle=0xf82455ce0。 ------
NFS servers commonly use a client's successful MOUNTPROC_MNT request request as an indication that the client has "mounted" the filesystem and may maintain this information in a file that lists the filesystems that clients currently have mounted. This information is removed from the file when the client transmits an MOUNTPROC_UMNT request. Upon receiving a successful reply to a MOUNTPROC_MNT request, a WebNFS client should send a MOUNTPROC_UMNT request to prevent an accumulation of "mounted" records on the server.
クライアントが持っている指示がファイルシステムを「取り付け」て、クライアントが現在取り付けたファイルシステムを記載するファイルでこの情報を保守するとき、NFSサーバは一般的にクライアントのうまくいっているMOUNTPROC_MNT要求要求を使用します。 クライアントがいつUMNTが要求するMOUNTPROC_を伝えるかというこの情報はファイルから取り除かれます。 MNTが要求するMOUNTPROC_にうまくいっている回答を受け取ると、WebNFSクライアントはUMNTがサーバにおける「取り付けられた」記録の蓄積を防ぐよう要求するMOUNTPROC_を送るべきです。
Note that the additional overhead of the PORTMAP and MOUNT protocols will have an effect on the client's binding time to the server and the dynamic port assignment of the MOUNT protocol may preclude easy firewall or proxy server transit.
PORTMAPと山のプロトコルの追加オーバーヘッドがクライアントのバインディング・タイムに影響をサーバに与えて、山のプロトコルのダイナミックなポート課題が簡単なファイアウォールかプロキシサーバトランジットを排除するかもしれないことに注意してください。
Callaghan Informational [Page 11] RFC 2054 WebNFS Client Specification October 1996
[11ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
The client may regain some performance improvement by utilizing a pathname prefix cache. For instance, if the client already has a filehandle for the pathname "a/b" then there is a good chance that the filehandle for "a/b/c" can be recovered by by a lookup of "c" relative to the filehandle for "a/b", eliminating the need to have the MOUNT protocol translate the pathname. However, there are risks in doing this. Since the LOOKUP response provides no indication of filesystem mountpoint crossing on the server, the relative LOOKUP may fail, since NFS requests do not normally cross mountpoints on the server. The MOUNT service can be relied upon to evaluate the pathname correctly - including the crossing of mountpoints where necessary.
クライアントは、パス名接頭語キャッシュを利用することによって、何らかの性能改良を取り戻すかもしれません。 例えば、クライアントが既にパス名のためのfilehandleを持つなら、そしてそこの「/b」は「/b/c」のためのfilehandleが「c」のルックアップで「/b」のためのfilehandleに比例して回復できるという十分な見込みです、山のプロトコルにパス名を翻訳させる必要性を排除して。 しかしながら、これをするのにおいてリスクがあります。 LOOKUP応答がサーバで交差するファイルシステム取付け位置のしるしを全く供給しないので、相対的なLOOKUPは失敗するかもしれません、NFS要求が通常サーバに関する取付け位置に交差していないので。正しくパス名を評価するために山のサービスを当てにすることができます--必要であるところに取付け位置の交差点を含んでいます。
9. Exploiting Concurrency
9. 並行性を利用します。
NFS servers are known for their high capacity and their responsiveness to clients transmitting multiple concurrent requests. For best performance, a WebNFS client should take advantage of server concurrency. The RPC protocol on which the NFS protocol is based, provides transport-independent support for this concurrency via a unique transaction ID (XID) in every NFS request.
NFSサーバはそれらの高容量とそれらの反応性で複数の同時要求を伝えるクライアントにとって知られています。 最も良い性能のために、WebNFSクライアントはサーバ並行性を利用するべきです。 NFSが議定書を作るRPCプロトコルは、基づいていて、あらゆるNFSのID(XID)が要求するユニークなトランザクションでこの並行性の輸送から独立しているサポートを提供します。
There is no need for a client to open multiple TCP connections to transmit concurrent requests. The RPC record marking protocol allows the client to transmit and receive a stream of NFS requests and replies over a single connection.
クライアントが同時要求を伝えるために複数のTCP接続を開く必要は全くありません。 プロトコルをマークするRPC記録で、クライアントは単独結合の上でNFS要求と回答のストリームを送受信できます。
9.1 Read-ahead
9.1は-先で読みます。
To keep the number of READ requests to a minimum, a WebNFS client should use the maximum transfer size that it and the server can support. The client can often optimize utilization of the link bandwidth by transmitting concurrent READ requests. The optimum number of READ requests needs to be determined dynamically taking into account the available bandwidth, link latency, and I/O bandwidth of the client and server, e.g. the following series of READ requests show a client using a single read-ahead to transfer a 128k file from the server with 32k READ requests:
READ要求の数を最小に抑えるために、WebNFSクライアントはそれとサーバがサポートすることができる最大の転送サイズを使用するべきです。 クライアントは、同時発生のREAD要求を伝えることによって、リンク帯域幅の利用をしばしば最適化できます。 READ要求の最適数は、ダイナミックにクライアントとサーバの利用可能な帯域幅、リンク潜在、およびI/O帯域幅を考慮に入れながら断固とする必要があります、例えば、以下のシリーズのREAD要求は32k READ要求でサーバから128kファイルを移すのに-先で読まれたシングルを使用することでクライアントを示しています:
READ XID=77 offset=0 for 32k -->
READ XID=78 offset=32k for 32k -->
<-- Data for XID 77
READ XID=79 offset=64k for 32k -->
<-- Data for XID 78
READ XID=80 offset=96k for 32k -->
<-- Data for XID 79
<-- Data for XID 80
READ XID=77は32k--32kのための>READ XID=78オフセット=32k--><--32kのためのXID77READ XID=79オフセット=64kのためのデータ--><--32kのためのXID78READ XID=80オフセット=96kのためのデータ--><--XID79<のためのデータ--XID80のためのデータのために=0を相殺します。
Callaghan Informational [Page 12] RFC 2054 WebNFS Client Specification October 1996
[12ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
The client must be able to handle the return of data out of order. For instance, in the above example the data for XID 78 may be received before the data for XID 77.
クライアントは故障していた状態でデータの復帰を扱うことができなければなりません。 例えば、上記の例では、XID77のためのデータの前にXID78のためのデータを受け取るかもしれません。
The client should be careful not to use read-ahead beyond the capacity of the server, network, or client, to handle the data. This might be determined by a heuristic that measures throughput as the download proceeds.
-先でサーバの容量を超えて読まれた使用、ネットワーク、またはどんなクライアントにとっても、クライアントは、データを扱うために慎重であるはずがありません。 これはダウンロードが続くときスループットを測定するヒューリスティックで決定するかもしれません。
9.2 Concurrent File Download
9.2 同時発生のファイルダウンロード
A client may combine read-ahead with concurrent download of multiple files. A practical example is that of Web pages that contain multiple images, or a Java Applet that imports multiple class files from the server.
クライアントは-先で倍数の同時発生のダウンロードで読んでいるファイルを結合するかもしれません。 実例は、複数のイメージを含むウェブページのもの、または複数のクラスがサーバからのファイルであることを意味するJavaアプレットです。
Omitting read-ahead for clarity, the download of multiple files, "file1", "file2", and "file3" might look something like this:
省略が明快、複数のファイルのダウンロードのために-先で読んだ、「file1"、「file2"、「file3"はこのように以下を見るかもしれません」。
LOOKUP XID=77 0x0 "file1" -->
LOOKUP XID=78 0x0 "file2" -->
LOOKUP XID=79 0x0 "file3" -->
<-- FH=0x01 for XID 77
READ XID=80 0x01 offset=0 for 32k -->
<-- FH=0x02 for XID 78
READ XID=81 0x02 offset=0 for 32k -->
<-- FH=0x03 for XID 79
READ XID=82 0x03 offset=0 for 32k -->
<-- Data for XID 80
<-- Data for XID 81
<-- Data for XID 82
LOOKUP XID=77 0x0、「file1"--、>LOOKUP XID=78 0x0、「file2"--、>LOOKUP XID=79 0x0、「file3"--><--XID77READ XID=80 0x01であることのFH=0x01は32k--><--32kのためのXID78READ XID=81 0x02オフセット=0--><--32kのためのXID79READ XID=82 0x03オフセット=0のためのFH=0x03--><--XID80<--XID81<のためのデータ--XID82のためのデータのためのデータのためのFH=0x02のために=0を相殺します」。
Note that the replies may be received in a different order from the order in which the requests were transmitted. This is not a problem, since RPC uses the XID to match requests with replies. A benefit of the request/reply multiplexing provided by the RPC protocol is that the download of a large file that requires many READ requests will not delay the concurrent download of smaller files.
回答が要求が伝えられたオーダーと異なったオーダーに受け取られるかもしれないことに注意してください。 RPCが回答に要求に合うのにXIDを使用するので、これは問題ではありません。 RPCプロトコルによって提供された要求/回答マルチプレクシングの利益は多くのREAD要求を必要とする大きいファイルのダウンロードが、より小さいファイルの同時発生のダウンロードを遅らせないということです。
Again, the client must be careful not to drown the server with download requests.
一方、クライアントは、ダウンロード要求に応じてサーバをおぼれないように慎重でなければなりません。
10.0 Timeout and Retransmission
10.0 タイムアウトとRetransmission
A WebNFS client should follow the example of conventional NFS clients and handle server or network outages gracefully. If a reply is not received within a given timeout, the client should retransmit the request with its original XID (described in Section 8 of RFC 1831).
WebNFSクライアントは、優雅に従来のNFSクライアントの例に倣っていて、サーバかネットワーク供給停止を扱うべきです。 回答が与えられたタイムアウトの中に受け取られないなら、クライアントはオリジナルのXID(RFC1831のセクション8では、説明される)との要求を再送するべきです。
Callaghan Informational [Page 13] RFC 2054 WebNFS Client Specification October 1996
[13ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
The XID can be used by the server to detect duplicate requests and avoid unnecessary work.
XIDはサーバによって使用されて、写し要求を検出して、不必要な仕事を避けることができます。
While it would seem that retransmission over a TCP connection is unnecessary (since TCP is responsible for detecting and retransmitting lost data), at the RPC layer retransmission is still required for recovery from a lost TCP connection, perhaps due to a server crash or, because of resource limitations, the server has closed the connection. When the TCP connection is lost, the client must re-establish the connection and retransmit pending requests.
TCP接続の上の「再-トランスミッション」が不要であるように(TCPはロストデータを検出して、再送するのに責任があるので)思えているだろうという間、恐らくサーバのため、ダウンするか、RPC層では、「再-トランスミッション」が迷子になったTCP接続からの回復にまだ必要です、リソース制限で、サーバは接続を終えました。 TCP接続が迷子になっているとき、クライアントは、接続を復職させて、未定の要求を再送しなければなりません。
The client should set the request timeout according to the following guidelines:
以下のガイドラインによると、クライアントは要求タイムアウトを設定するべきです:
- A timeout that is too small may result in the
wasteful transmission of duplicate requests.
The server may be just slow to respond, either because
it is heavily loaded, or because the link latency is high.
- 小さ過ぎるタイムアウトは写し要求の無駄な伝達をもたらすかもしれません。 サーバは反応させるのがただ遅いかもしれません、それが大いにロードされるか、またはリンク潜在が高いので。
- A timeout that is too large may harm throughput if
the request is lost and the connection is idle waiting
for the retransmission to occur.
- 要求が無くなって、「再-トランスミッション」が現れるのを待つのにおいて接続が無駄であるなら、大き過ぎるタイムアウトはスループットに害を及ぼすかもしれません。
- The optimum timeout may vary with the server's
responsiveness over time, and with the congestion
and latency of the network.
- 最適なタイムアウトは時間がたつにつれてのサーバの反応性、混雑、およびネットワークの潜在で異なるかもしれません。
- The optimum timeout will vary with the type of NFS
request. For instance, the response to a LOOKUP
request will be received more quickly than the response
to a READ request.
- NFS要求のタイプに従って、最適なタイムアウトは異なるでしょう。 例えば、READ要求への応答よりすぐにLOOKUP要求への応答を受けるでしょう。
- The timeout should be increased according to an
exponential backoff until a limit is reached.
For instance, if the timeout is 1 second, the
first retransmitted request should have a timeout of
two seconds, the second retransmission 4 seconds, and
so on until the timeout reaches a limit, say 30 seconds.
This avoids flooding the network with retransmission
requests when the server is down, or overloaded.
- 指数のbackoffによると、限界に達するまで、タイムアウトは増強されるべきです。 例えば、4秒の、そして、タイムアウトまでとてもオンな「再-トランスミッション」が限界に達する秒に、タイムアウトが1秒、最初の再送された要求には2秒のタイムアウトがあるべきであるということであるなら30秒言ってください。 これは、サーバが下がる、または積みすぎられるとき、「再-トランスミッション」要求でネットワークをあふれさせるのを避けます。
As a general rule of thumb, the client should start with a long timeout until the server's responsiveness is determined. The timeout can then be set to a value that reflects the server's responsiveness to previous requests.
概して親指では、サーバの反応性が決定するまで、クライアントは長いタイムアウトから始めるべきです。 そして、前の要求にサーバの反応性を反映する値にタイムアウトを設定できます。
Callaghan Informational [Page 14] RFC 2054 WebNFS Client Specification October 1996
[14ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
11.0 Bibliography
11.0 図書目録
[RFC1808] Fielding, R.,
"Relative Uniform Resource Locators", RFC 1808,
June 1995.
http://www.internic.net/rfc/rfc1808.txt
[RFC1808] フィールディング、R.、「相対的なUniform Resource Locator」、RFC1808、6月1995日の http://www.internic.net/rfc/rfc1808.txt
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call
Protocol Specification Version 2", RFC 1831,
August 1995.
http://www.internic.net/rfc/rfc1831.txt
[RFC1831]Srinivasan、R.、「RPC:」 遠隔手続き呼び出しプロトコル仕様バージョン2インチ、RFC1831、8月1995日の http://www.internic.net/rfc/rfc1831.txt
[RFC1832] Srinivasan, R, "XDR: External Data Representation
Standard", RFC 1832, August 1995.
http://www.internic.net/rfc/rfc1832.txt
[RFC1832]Srinivasan、R、「XDR:」 「外部データ表現規格」、RFC1832、8月1995日の http://www.internic.net/rfc/rfc1832.txt
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC
Version 2", RFC 1833, August 1995.
http://www.internic.net/rfc/rfc1833.txt
[RFC1833] Srinivasan、R.、「ONC RPCでプロトコルをバージョン2インチ縛るRFC1833、8月1995日の http://www.internic.net/rfc/rfc1833.txt 」
[RFC1094] Sun Microsystems, Inc., "Network Filesystem
Specification", RFC 1094, March 1989. NFS
version 2 protocol specification.
http://www.internic.net/rfc/rfc1094.txt
[RFC1094]サン・マイクロシステムズ・インク、「ネットワークファイルシステム仕様」、RFC1094、1989年3月。 NFSバージョン2プロトコル仕様 http://www.internic.net/rfc/rfc1094.txt
[RFC1813] Sun Microsystems, Inc., "NFS Version 3 Protocol
Specification," RFC 1813, June 1995. NFS version
3 protocol specification.
http://www.internic.net/rfc/rfc1813.txt
[RFC1813]サン・マイクロシステムズ・インク、「NFSバージョン3プロトコル仕様」、RFC1813、1995年6月。 NFSバージョン3プロトコル仕様 http://www.internic.net/rfc/rfc1813.txt
[RFC2055] Callaghan, B., "WebNFS Server Specification",
RFC 2055, October 1996.
http://www.internic.net/rfc/rfc2055.txt
[RFC2055] キャラハン、B.、「WebNFSサーバ仕様」、RFC2055、10月1996日の http://www.internic.net/rfc/rfc2055.txt
[Sandberg] Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh,
B. Lyon, "Design and Implementation of the Sun
Network Filesystem," USENIX Conference
Proceedings, USENIX Association, Berkeley, CA,
Summer 1985. The basic paper describing the
SunOS implementation of the NFS version 2
protocol, and discusses the goals, protocol
specification and trade-offs.
[サンドベルイ]サンドベルイ、R.、D.ゴールドバーグ、S.Kleiman、D.ウォルシュ、B.リヨン、「太陽のデザインと実装はファイルシステムをネットワークでつなぎます」、USENIX会議の議事録、USENIX協会、バークレー(カリフォルニア)1985年夏。 NFSバージョン2のSunOS実装について説明する基本的な紙は、目標、プロトコル仕様、およびトレードオフを議定書の中で述べて、議論します。
[X/OpenNFS] X/Open Company, Ltd., X/Open CAE Specification:
Protocols for X/Open Internetworking: XNFS,
X/Open Company, Ltd., Apex Plaza, Forbury Road,
Reading Berkshire, RG1 1AX, United Kingdom,
1991. This is an indispensable reference for
[X/OpenNFS] X/Open会社Ltd.、X/Open CAE仕様: X/Openインターネットワーキングのためのプロトコル: XNFS X/Open会社Ltd.、頂点広場、フォーベリー道路がバークシャーを読むRG1 1AX、イギリスの1991。 これは不可欠の参照です。
Callaghan Informational [Page 15] RFC 2054 WebNFS Client Specification October 1996
[15ページ]RFC2054WebNFSクライアント仕様1996年10月の情報のキャラハン
NFS version 2 protocol and accompanying
protocols, including the Lock Manager and the
Portmapper.
LockマネージャとPortmapperを含むNFSバージョン2プロトコルと付随のプロトコル。
[X/OpenPCNFS] X/Open Company, Ltd., X/Open CAE Specification:
Protocols for X/Open Internetworking: (PC)NFS,
Developer's Specification, X/Open Company, Ltd.,
Apex Plaza, Forbury Road, Reading Berkshire, RG1
1AX, United Kingdom, 1991. This is an
indispensable reference for NFS version 2
protocol and accompanying protocols, including
the Lock Manager and the Portmapper.
[X/OpenPCNFS] X/Open会社Ltd.、X/Open CAE仕様: X/Openインターネットワーキングのためのプロトコル: (PC)NFS開発者の仕様、X/Open会社Ltd.、頂点広場、フォーベリー道路がバークシャーを読むRG1 1AX、イギリスの1991。 これはLockマネージャとPortmapperを含むNFSバージョン2プロトコルと付随のプロトコルの不可欠の参照です。
12. Security Considerations
12. セキュリティ問題
Since the WebNFS server features are based on NFS protocol versions 2 and 3, the RPC based security considerations described in RFC 1094, RFC 1831, and RFC 1832 apply here also.
WebNFSサーバ機能がNFSプロトコルバージョン2と3に基づいているので、また、RFC1094、RFC1831、およびRFC1832で説明されたRPCのベースのセキュリティ問題はここに適用されます。
Clients and servers may separately negotiate secure connection schemes for authentication, data integrity, and privacy.
クライアントとサーバは別々に認証、データ保全、およびプライバシーの安全な接続体系を交渉するかもしれません。
13. Acknowledgements
13. 承認
This specification was extensively reviewed by the NFS group at SunSoft and brainstormed by Michael Eisler.
この仕様は、SunSoftでNFSグループによって手広く見直されて、マイケル・アイスラーによってブレインストーミングされました。
14. Author's Address
14. 作者のアドレス
Address comments related to this document to:
アドレスコメントは以下のことのためにこのドキュメントに関連しました。
nfs@eng.sun.com
nfs@eng.sun.com
Brent Callaghan Sun Microsystems, Inc. 2550 Garcia Avenue Mailstop Mpk17-201 Mountain View, CA 94043-1100
ブレントキャラハンサン・マイクロシステムズ・インク2550ガルシア・アベニューMailstop Mpk17-201マウンテンビュー、カリフォルニア94043-1100
Phone: 1-415-786-5067 Fax: 1-415-786-5896 EMail: brent.callaghan@eng.sun.com
以下に電話をしてください。 1-415-786-5067 Fax: 1-415-786-5896 メールしてください: brent.callaghan@eng.sun.com
Callaghan Informational [Page 16]
キャラハンInformationalです。[16ページ]
一覧
スポンサーリンク
