rfc2054.txt

RFC 的详细文档！

   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.

   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.



Callaghan                    Informational                     [Page 11]

RFC 2054              WebNFS Client Specification           October 1996


   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.

9. Exploiting Concurrency

   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.

   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.

9.1 Read-ahead

   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 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




Callaghan                    Informational                     [Page 12]

RFC 2054              WebNFS Client Specification           October 1996


   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.

   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

   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.

   Omitting read-ahead for clarity, the download of multiple files,
   "file1", "file2", and "file3" might look something like this:

        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

   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.

   Again, the client must be careful not to drown the server with
   download requests.

10.0 Timeout and 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).



Callaghan                    Informational                     [Page 13]

RFC 2054              WebNFS Client Specification           October 1996


   The XID can be used by the server to detect duplicate requests and
   avoid unnecessary work.

   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.

   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.

        - 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.

   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


11.0 Bibliography

   [RFC1808]       Fielding, R.,
                   "Relative Uniform Resource Locators", RFC 1808,
                   June 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

   [RFC1832]       Srinivasan, R, "XDR: External Data Representation
                   Standard", RFC 1832, August 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

   [RFC1094]       Sun Microsystems, Inc., "Network Filesystem
                   Specification", RFC 1094, March 1989.  NFS
                   version 2 protocol specification.
                   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

   [RFC2055]       Callaghan, B., "WebNFS Server Specification",
                   RFC 2055, October 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.

   [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



Callaghan                    Informational                     [Page 15]

RFC 2054              WebNFS Client Specification           October 1996


                   NFS version 2 protocol and accompanying
                   protocols, including the Lock Manager and the
                   Portmapper.

   [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.

12. Security Considerations

   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.

   Clients and servers may separately negotiate secure connection
   schemes for authentication, data integrity, and privacy.

13. Acknowledgements

   This specification was extensively reviewed by the NFS group at
   SunSoft and brainstormed by Michael Eisler.

14. Author's Address

   Address comments related to this document to:

   [e-mail]


   Brent Callaghan
   Sun Microsystems, Inc.
   2550 Garcia Avenue
   Mailstop Mpk17-201
   Mountain View, CA 94043-1100

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]








Callaghan                    Informational                     [Page 16]