WebNFS Server Specification
RFC 2055
Document | Type |
RFC - Informational
(October 1996; No errata)
Was draft-rfced-info-callaghan2 (individual)
|
|
---|---|---|---|
Author | Brent Callaghan | ||
Last updated | 2013-03-02 | ||
Stream | Legacy stream | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2055 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group B. Callaghan Request for Comments: 2055 Sun Microsystems, Inc. Category: Informational October 1996 WebNFS Server Specification Status of this 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 the specifications for a server of WebNFS clients. WebNFS extends the semantics of versions 2 and 3 of the NFS protocols to allow clients to obtain filehandles more easily, without recourse to the portmap or MOUNT protocols. In removing the need for these protocols, WebNFS clients see benefits in faster response to requests, easy transit of firewalls and better server scalability This description is provided to facilitate compatible implementations of WebNFS servers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. TCP vs UDP . . . . . . . . . . . . . . . . . . . . . . . 2 3. Well-known Port . . . . . . . . . . . . . . . . . . . . . 2 4. Server Port Monitoring . . . . . . . . . . . . . . . . . . 3 5. Public Filehandle . . . . . . . . . . . . . . . . . . . . 3 5.1 Version 2 Public Filehandle . . . . . . . . . . . . . . 3 5.2 Version 3 Public Filehandle . . . . . . . . . . . . . . 4 6. Multi-component Lookup . . . . . . . . . . . . . . . . . . 4 6.1 Canonical Path vs. Native Path . . . . . . . . . . . . . 5 6.2 Symbolic Links . . . . . . . . . . . . . . . . . . . . . 6 6.3 Export Spanning Pathnames . . . . . . . . . . . . . . . 6 7. Location of Public Filehandle . . . . . . . . . . . . . . 7 8. Index Files . . . . . . . . . . . . . . . . . . . . . . . 7 9. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9 12. Author's Address . . . . . . . . . . . . . . . . . . . . . 10 Callaghan Informational [Page 1] RFC 2055 WebNFS Server Specification October 1996 1. Introduction The NFS protocol provides access to shared filesystems across networks. It is intended to be machine, operating system, network architecture, and transport independent. The protocol currently exists in two versions: version 2 [RFC1094] and version 3 [RFC1813], both built on Sun RPC [RFC1831] and its associated eXternal Data Representation (XDR) [RFC1832]. This document assumes some familiarity with the NFS protocol and underlying RPC protocols. WebNFS servers implement semantic extensions to both versions of the NFS protocol to support a lightweight binding mechanism for conventional or web browser clients that need to communicate with NFS servers across the Internet. a WebNFS server supports the public filehandle and multi-component lookup features described herein, as well as meeting some additional requirements. For a description of WebNFS client requirements, read RFC 2054. 2. TCP vs 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. A WebNFS client will first attempt to connect to its server with a TCP connection. If the server refuses the connection, the client will attempt to use UDP. All WebNFS servers should support client use of TCP and must support UDP. 3. Well-known Port 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. 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 Callaghan Informational [Page 2] RFC 2055 WebNFS Server Specification October 1996 constant port assignment, 2049, for both UDP and TCP.Show full document text