ACCESS第二十九章: 网络文件系统

29.1 引言

本章中我们要讨论另一个常用之应用程序:NFS(网络文件系统),它呢客户程序提供透明底文本访问。NFS的底蕴是Sun
RPC:远程过程调用。我们首先必须描述一下RPC。

客户程序使用NFS不待举行什么特别的做事,当NFS内核检测及被访的文本在一个NFS服务器时,就会见活动发出一个访问该公文之RPC调用。

咱对NFS如何访问文件的细节并不感兴趣,只对她什么下Internet的商议,尤其是UDP协议,感兴趣。

29.2 Sun远程过程调用

大部分之纱程序设计都是编一些调用系统提供的函数来形成一定的纱操作的应用程序。例如,一个函数完成TCP的积极性打开,另一个得TCP的低落打开,一个函数在一个TCP连接上发送数据,另一个装置一定的说道选项(如激活TCP的keepalive定时器)。在1.15节我们提到了一点儿个常因此的用于网络编程的函数集(API):插口(socket)和TLI。正像客户端和劳动器端运行的操作系统可能会见无同等一样,双方以的API也恐怕会见无均等。由通信协议和下协议决定一对准客户和服务器是否好彼此通信。如果简单令主机连接在一个网上,并且都产生一个TCP/IP的贯彻,那么相同光主机及之一个应用C语言编写的、使用插口和TCP的Unix客户程序可以与另外一样玉主机及的一个运用COBOL语言编写的、使用其它API和TCP的大型机服务器进行通信。

貌似的话,客户发送命令于服务器,服务器向客户发送应答。目前为止,我们谈论了之具备应用程序—Ping,Traceroute,选路守护程序、以及DNS、TFTP、BOOTP、SNMP、Telnet、FTP和SMTP的客户及服务器—都是动这种艺术实现的。

长途过程调用RPC(Remote Procedure
Call)是同样栽不同之大网程序设计方式。客户程序编写时只是调用了服务器程序提供的函数。这就是程序员所发到之,实际上有了下有动作。

1:当客户程序调用远程的长河时,它实际仅是调用了一个居本机上的、由RPC程序包生成的函数。这个函数被称呼客户残桩(stub)。客户残桩将经过的参数封装成一个网报文,并且用这报文发送给服务器程序。

2:服务器主机上之一个服务器残桩负责接这网络报文。它由网络报文中提取参数,然后调用应用程序员编写的服务器过程。

3:当服务器函数返回时,它回到到服务器残桩。服务器残桩提取返回值,把返回值封装成一个网络报文,然后以报文发送给客户残桩。

4:客户残桩从收到至的网报文中取出返回值,将其回来给客户程序。

纱程序设计是经残桩和采取诸如插口或TLI的某部API的RPC库例程来促成之,但是用户程序—客户程序和让客户程序调用的服务器过程—不见面跟这个API打交道。客户应用程序只是调用服务器的长河,所有网络程序设计的细节还为RPC程序包、客户残桩和服务器残桩所藏。

一个RPC程序包供了无数好处。

1:程序设计更为爱,因为非常少或者几乎从不干网络编程。应用程序设计员只需要编制一个客户程序和客户程序调用的服务器过程。

2:如果采取了一个不可靠的磋商,如UDP,像过和重传等细节就由于RPC程序包来处理。这就是简化了用户应用程序。

3:RPC库为参数和返回值的传提供任何索要的数目易。例如,如果参数是由整数和浮点数组成的,RPC程序包处理整数和浮点数在客户机和服务器主机及囤积的两样款式。这个作用简化了于异构环境面临的客户与服务器的编码问题。

RPC程序统筹的底细可以参照参考文献[Stevens
1990]的第18节。两只常因此的RPC程序包是Sun
RPC和开放软件基金(OSF)分布式计算环境(DCE)的RPC程序包。我们对RPC的志趣在于想了解Sun
RPC中经过调用和过程返回报文的样式,因为本章中讨论的纱文件系统使用了它们。Sun
RPC的第2版定义在RFC 1057 [Sun Microsystems 1988a]中。

Sun RPC

SunRPC有有限单版。一个本子建立在插口API基础及,和TCP和UDP打交道。另一个名TI-RPC的(独立为运输层),建立于TLIAPI基础及,可以与基础提供的任何运输层协议打交道。尽管本章中我们仅仅谈谈TCP和UDP,从讨论的观点来拘禁,两者是同样的。

贪图29-1亮的是利用UDP时,一个RPC过程调用报文的格式。IP首部和UDP首部是标准的首部,我们就以图3-1和图11-2蒙显了。UDP首部以下是RPC程序包定义的片。

祈求29-1 RPC过程调用报文作为一个UDP数据报的格式

业务标识符(XID)由客户程序设置,由服务器程序返回。当客户收取一个应对,它将服务器返回的XID与它发送的呼吁的XID相较。如果不般配,客户就放弃这个报文,等待从服务器返回的产一个报文。每次客户产生一个新的RPC,它就会见改报文的XID。但是要客户重传一个在先发送了的RPC(因为它从不收到服务器的一个应对),重传报文的XID不会见改。

调用(call)变量在过程调用报文中安为0,在承诺答报文中设置为1。当前之RPC版本是2。接下来三独变量:程序号、版本号和过程号,标识了服务器上叫调用的一定过程。

关系(credential)字段标识了客户。有些情况下,证书字段设置也空值;另外一些情形下,证书字段设置为数字形式之客户的用户号和组号。服务器可以查看证书字段因决定是否履要的长河。验证(verifier)字段用于采取了DES加密的安RPC。尽管证书字段和认证字段是可转移长的字段,它们的长也视作字段的如出一辙片段被编码。

连通下去是过程参数(procedure
parameter)字段。参数的格式依赖让远程过程的概念。接收者(服务器残桩)如何知道参数字段的轻重也?既然用的凡UDP共商,UDP数据报的大小减去证明字段以上有字段的长短就是参数的分寸。如果利用的无是UDP而是TCP,因为TCP是一个字节流协议,没有记录边界,所以没固定的长。为了化解这题目,在TCP首部同XID之间加了一个4字节的长度字段,告诉接收者这个RPC调用由小字节组成。这吗使得一个RPC调用报文在必要常常得用多单TCP段来导(DNS使用了类似的技巧,参见习题14-4)。

希冀29-2显了一个RPC应答报文的格式。当远程过程返回时,服务器残桩将之报文发送给客户残桩。

贪图29-2 RPC应答报文作为一个UDP数据报的格式

回答报文中的XID字段是由调用报文的XID字段复制而来。应答字段设置也1,以分别为调用报文。如果调用报文被受,状态字段设置为0(如果RPC的版本号不为2,或者服务器不可知辨识客户之位置,调用报文可能给拒)。安全的RPC使用说明字段来标识服务器。

倘远程过程调用成功,接受状态字段置为0。一个非零的值可能意味着一个免合法的版本号或者一个请勿合法的过程号。如果用的非是UDP而是TCP,如同RPC调用报文一样,在TCP首部暨XID字段之间插入一个4字节的长度字段。

29.3 XDR:外部数据表示

表面数据表示XDR(eXternal Data
Representation)是一个标准,用来对RPC调用报文和回应报文中的值进行编码。这些价值包括RPC首统字段(XID、程序号、接受状态等)、过程参数和过程结果。采用规范的方式对这些价值进行编码使得一个网面临的客户可以调用另一个例外架构的体系受到的一个历程。XDR在RFC
1014遭受定义[Sun Microsystems 1987]。

XDR定义了众数据类型以及它们如何在一个RPC报文中传的现实形式(如比特顺序,字节顺序等)。发送者必须利用XDR格式构造一个RPC报文,然后接收者将XDR格式的报文转换为本机的表示形式。例如,在觊觎29-1及图29-2饱受,我们来得的富有整数值(XID、调用字段、程序号等)都是4字节的平头。在XDR中,所有的整数的确占据4只字节。XDR支持的其余数据类型包括无符号整数、布尔型、浮点数、定长数组、可变长数组和结构。

29.4 端口映射器

涵盖远程过程的RPC服务器程序使用的凡现端口,而非是闻名端口。这便用某种形式之“注册”程序来跟哪一个RPC程序采取了啦一个即端口。在Sun
RPC中,这个注册程序为叫作端口映射器(port mapper)。

“端口”这个词作为Internet协议族的一个特征,来自于TCP和UDP端口号。既然TIRPC可以工作在任何运输层协议之上,而不仅仅是TCP和UDP,所以使用TI-RPC的系统中(如SVR4和Solaris 2.2),端口映射器的名字变成了rpcbind。下面我们继续使用更为常见的端口映射器的名字。

良当然地,端口映射器本身必须出一个名牌端口:UDP端口111以及TCP端口111。端口映射器也就是一个RPC服务器程序。它产生一个程序号(100000)、一个版本号(2)、一个TCP端口111跟一个UDP端口111。服务器程序使用RPC调用往端口映射器注册自身,客户程序使用RPC调用往端口映射器询问。端口映射器提供四只服务过程:

1:PMAPPROC_SET。一个RPC服务器启动时调用这个历程,注册一个程序号、版本号和包含一个端口号的商事。

2:PMAPPROC_UNSET。RPC服务器调用此过程来删除一个早已注册的照。

3:PMAPPROC_GETPORT。一个RPC客户启动时调用此过程。根据一个加以的程序号、版本号和商来抱注册的端口号。

4:PMAPPROC_DUMP。返回端口映射器数据库中拥有的记录(每个记录包括程序号、版本号、协议及端口号)。

在一个RPC服务器程序启动,接着被一个RPC客户程序调用的经过遭到,进行了以下一些手续:

1:一般情况下,当系统引导时,端口映射器必须首先启动。它创建一个TCP端点,并且被动打开TCP端口111。它吧创一个UDP端点,并且在UDP端口111守候着UDP数据报的赶来。

2:当RPC服务器程序启动时,它也它们所支撑之次第的诸一个版本创建一个TCP端点和一个UDP端点(一个加以的RPC程序可以支撑多个版本。客户调用一个服务器过程时,说明她想使啊一个版)。两个端点各自绑定一个现端口(TCP端口号及UDP端口号是否一律无关紧要)。服务器通过RPC调用端口映射器底PMAPPROC_SET过程,注册每一个序、版本、协议及端口号。

3:当RPC客户程序启动时,它调用端口映射器底PMAPPROC_GETPORT过程来博取一个指定程序、版本与商量的临时端口号。

4:客户发送一个RPC调用报文给第3步回去的捧口号。如果采取的是UDP,客户只是发送一个蕴含RPC调用报文(见图29-1)的UDP数据报到服务器相应的UDP端口。服务器发送一个暗含RPC应答报文(见图29-2)的UDP数据报到客户作为响应。

如果使用的是TCP,客户针对服务器的TCP端口号做一个积极向上打开,然后在成立之TCP连接上发送一个RPC调用报文。服务器作为响应,在连达发送一个RPC应答报文。

次rpcinfo(8)打印了端口映射器中当前之照射记录(它调用了端口映射器底PMAPPROC_DUMP过程)。这里给有底凡超人的输出:

可以看有些序真的支撑多单本子。在端口映射器中,每一个程序号、版本号和协议的结都起和好之端口号映射。

安守护程序(mount
daemon)的少数单版本可以通过一样的TCP端口号(702)和同样的UDP端口号(699)来走访,而加锁管理程序(lock
manager)的每个版本都有各自不同的捧口号。

29.5 NFS协议

运NFS,客户可透明地访问服务器上之文书与文件系统。这不一于提供文件传输的FTP(第27回)。FTP会产生文书一个完的副本。NFS只看一个经过引用文件的那片,并且NFS的一个目的就是是叫这种访问透明。这便代表任何能够访问一个地方文件之客户程序不需要举行其他改动,就应当能访问一个NFS文件。

NFS是一个施用Sun
RPC构造的客户服务器应用程序。NFS客户通过为一个NFS服务器发送RPC请求来访问该达成之文书。尽管这同一办事好采用相似的用户进程来实现—即NFS客户可是一个用户进程,对服务器进行显式调用。而服务器也得以是一个用户进程—因为个别只理由,NFS一般不这样实现。首先,访问一个NFS文件必须对客户透明。因此,NFS的客户调用是出于客户操作系统代表用户进程来成功的。第二,出于效率的设想,NFS服务器在服务器操作系统被实现。如果NFS服务器是一个用户进程,每个客户要和服务器对(包括读与描写的数目)将不得不以基础和用户进程中进行切换,这个代价不过老。

本节遇,我们着眼在RFC1094中证的第2版本的NFS [Sun Microsystems
1988b]。[X/Open1991]吃让闹了Sun
RPC、XDR和NFS的一个还好的叙述。[Stern
1991]受起了采取以及治本NFS的细节。第3版本的NFS协议于1993年披露,我们当29.7节遭逢针对它们做一个简易的叙述。

希冀29-3形了一个NFS客户与一个NFS服务器的超人配置,图备受发生成千上万地方要留意。

贪图29-3 NFS客户及NFS服务器的榜首配置

1:访问的凡一个地面文件要一个NFS文件对于客户的话是透明底。当文件给辟时,由基础决定就或多或少。文件为辟之后,内核将地面文件之具备援传递让名吧“本地文件访问”的框中,而将一个NFS文件的有着援传递让名吧“NFS客户”的框中。

2:NFS客户通过它们的TCP/IP模块于NFS服务器发送RPC请求。NFS主要利用UDP,最新的贯彻啊堪下TCP。

3:NFS服务器在端口2049收作为UDP数据报的客户要。尽管NFS可以让实现成为用端口映射器,允许服务器使用一个临时端口,但是多数之落实都是一直指定UDP端口2049。

4:当NFS服务器收到一个客户要时,它以这个要传递给当地文件访问例程,后者访问服务器主机及之一个地方的磁盘文件。

5:NFS服务器需要花得之时来拍卖一个客户之求。访问当地文件系统一般为急需一些工夫。在就段时日距离内,服务器不该阻碍其他的客户要得到服务。为了促成这同样效益,大多数底NFS服务器都是多线程的—即服务器的水源中实际有差不多个NFS服务器在运转。具体怎么落实依靠让不同的操作系统。既然大多数底Unix内核不是多线程的,一个联手的技艺就是是启动一个用户进程(常给誉为nfsd)的大多个实例。这个实例执行一个系统调用,使和谐当作一个基础进程保留在操作系统的本中。

6:同样,在客户主机上,NFS客户需要花得之辰来拍卖一个用户进程的求。NFS客户于服务器主机来一个RPC调用,然后等待服务器的对答。为了让采用NFS的客户主机及的用户进程提供更多之并发性,在客户基本中貌似运行着多只NFS客户。同样,具体实现为靠让操作系统。Unix系统时以类似于NFS服务器的技巧:一个受作biod的用户进程执行一个网调用,作为一个基本进程保留在操作系统的基本中。

大部之Unix主机可以看作一个NFS客户,一个NFS服务器,或者双方都是。大多数PC机的落实(MS-DOS)只提供了NFS客户实现。大多数的IBM大型机只提供了NFS服务器功能。

NFS实际上不仅是因为NFS协议组成。图29-4示了NFS使用的不比RPC程序。

祈求29-4 NFS使用的异RPC程序

在这个图中,程序的版本是在SunOS 4.1.3中使用的。更新的实现提供了其中一些程序更新的版本。例如,Solaris 2.2还支持端口映射器的第3版和第4版,以及安装守护程序的第2版。SVR4支持第3版的端口映射器。

每当客户会访问服务器上的文件系统之前,NFS客户主机必须调用安装守护程序。我们以脚讨论安装守护程序。

加锁管理程序和状态监视器允许客户锁定一个NFS服务器上文件的有区域。这片个次独立为NFS协议,因为加锁需要知道客户和服务器的状态,而NFS本身在服务器上是随便状态的(下面我们对NFS的无状态会介绍得还多)。[X/Open
1991]的第9,10以及11章说明了动用加锁管理程序和状态监视器进行NFS文件锁定的长河。

29.5.1 文件句柄

NFS中一个基本概念是文件句柄(file
handle)。它是一个请勿透明(opaque)的目标,用来引用服务器上的一个文件或者目录。不透明指的凡服务器创建文件句柄,把她传递让客户,然后客户走访文件时,使用相应的文件句柄。客户无会见翻动文件句柄的始末—它的始末只有针对服务器出义。

老是一个客户过程打开一个事实上在一个NFS服务器上的文本时,NFS客户就见面从NFS服务器那里得到该公文之一个文本句柄。每次NFS客户呢用户进程读或写文件时,文件句柄就见面招于服务器因为指定给聘的公文。

一般情形下,用户进程不会见和文件句柄打交道—只有NFS客户与NFS服务器将文件句柄传来传去。在第2版的NFS中,一个文书句柄占据32只字节,第3本中增加为64个字节。

  Unix服务器一般在文件句柄中存储下面的信息:文件系统标识符(文件系统最大和最小的设备号),i-node号(在一个文件系统中唯一的数值)和一个i-node的生成码(每当一个i-node被一个不同的文件重用时就改变的数值)。
29.5.2 安装协议

客户要以走访服务器上一个文件系统中的文书前,使用安装协议安装很文件系统。一般情况下,这是在客户主机引导时做到的。最后的结果就是是客户获得服务器文件系统的一个文本句柄。

贪图29-5著了一个Unix客户来mount(8)命令所产生的状,它证明一个NFS的安装过程。

祈求29-5 使用Unixmount命令的安协议

各个有了底的动作。

1:服务器上之端口映射器一般以服务器主机引导时让启动。

2:安装守护程序(mountd)在端口映射器后于启动。它创建了一个TCP端点和一个UDP端点,并各自赋予一个即之端口号。然后她以端口映射器中注册这些端口号。

3:在客户机上执行mount命令,它为服务器上之端口映射器发出一个RPC调用来抱服务器上安装守护程序的端口号。客户及端口映射器交互既可使TCP也得使UDP,但貌似以UDP。

4:端口映射器应答以安守护程序的端口号。

5:mount命令于安装守护程序来一个RPC调用来安服务器上之一个文件系统。同样,既可以TCP也得使UDP,但貌似采取UDP。服务器现在足证明客户,使用客户的IP地址和端口号来识别是否同意客户安装指定的文件系统。

6:安装守护程序应答以指定文件系统的文书句柄。

7:客户机上的mount命令发出mount系统调用将第5步回去的公文句柄和客户机上的一个地面安装点联系起来。文件句柄被储存于NFS客户代码中,从今日起,用户进程对于大服务器文件系统的别样引用都将自利用是文件句柄开始。

上述实现技能以有的安装处理,除了客户机上的mount系统调用,都坐落用户进程遭到,而未是放在内核中。我们展示的老三独程序—mount命令、端口映射器和安装守护程序—都是用户进程。

当一个例子,在我们的主机sun(一个NFS客户机)上实行:

sun # mount -t nfs bsdi:/usr /nfs/bsdi/usr

夫命令将主机bsdi(一个NFS服务器)上的/usr目录安装成为当地文件系统/nfs/bsdi/usr。图29-6形了结果。

祈求29-6 将bsdi:/usr 目录安装成主机 sun 上的/nfs/bsdi/usr 目录

当我们引用客户机sun上之/nfs/bsdi/usr/rstevens/hello.c文件时,实际上引用的是服务器bsdi上的文件/usr/rstevens/hello.c。

29.5.3 NFS过程

今咱们讲述NFS服务器提供的15独过程(使用的个数和NFS过程的其实个数不同等,因为咱们管其仍职能区划了组)。尽管NFS被规划成可以于不同之操作系统及工作,而不只是Unix系统,但是有些供Unix功能的长河可能不给别操作系统支持(例如硬链接、符号链接、组的属主和执行权等)。[Stevens
1992]的第4章节包含了Unix文件系统其他的片段消息,其中小被NFS采用。

1:GETATTR。返回一个文书之习性:文件类型(一般文件,目录等)、访问权限、文件大小、文件的属于主者及上次访问时等信息。

2:SETATTR。设置一个文本的属性。只同意设置文件属性的一个子集:访问权限、文件之属主、组的属主、文件大小、上次访问时跟上次修改时间。

3:STATFS。返回一个文件系统的状态:可用空间的轻重、最佳传送大小等。例如Unix的df命令使用这过程。

4:LOOKUP。查找一个文本。每当一个用户进程打开一个NFS服务器上的一个文书时,NFS客户调用此过程。

5:READ。从一个文件中读数据。客户说明文件的句柄、读操作的启幕位置及朗诵数据的尽酷字节数(最多8192单字节)。

6:WRITE。对一个文本进行摹写操作。客户说明文件的句柄、开始位置、写多少的字节数和而写的数码。

7:CREATE。创建一个文书。

8:REMOVE。删除一个文件。

9:RENAME。重命名一个文本。

10:LINK。为一个文本构造一个硬链接。硬链接是一个Unix的概念,指的凡磁盘中的一个文件可以发自由多单目录项(即名,也于作坚强链接)指于它们。

11:SYMLINK。为一个文件创建一个记链接。符号链接是一个包含其他一个文件名字的文书。大多数引用符号链接的操作(例如,打开)实际上引用的凡标志链接所负的文书。

12:READLINK。读一个标志链接。即返符号链接所依的文书之名字。

13:MKDIR。创建一个索引。

14:RMDIR。删除一个目。

15:READDIR。读一个索引。例如,Unix的ls命令下这个过程。

这些经过实际上有一个前缀NFSPROC_,我们拿它们大概了。

29.5.4 UDP还是TCP

NFS最初是为此UDP写的,所有的厂商还提供了这种实现。最新的有的贯彻啊支撑TCP。TCP支持至关重要用来广域网,它好要文件操作更快。NFS已经不再局限为局域网的采用。

当从LAN转换到W N时,网络的动态特征变化得非常酷。往返时间(round-trip
time)变动范围非常,拥塞经常有。WAN的这些特色使得我们着想使用有TCP属性的算法——慢启动,但是可免拥塞。既然UDP没有供任何类似的物,那么以NFS客户及服务器上增加同样的算法或者下TCP。

29.5.5 TCP上的NFS

伯克利实现的Net/2NFS支撑UDP或者TCP。[Macklem
1991]讲述了是实现。让咱们看一下以TCP有啊两样。

1:当服务器主机进行带时,它启动一个NFS服务器,后者被动打开TCP端口2049,等待着客户的连年要。这一般是任何一个NFS服务器,正常的NFS
UDP服务器在UDP端口2049等候在进的UDP数据报。

2:当客户采用TCP安装服务器上之文件系统时,它对服务器上的TCP端口2049召开一个主动打开。这样就算也是文件系统在客户和服务器之间形成了一个TCP连接。如果同的客户安装同样服务器上的任何一个文件系统,就会见创造另一个TCP连接。
3:客户及服务器在它们连接的双面都要设置TCP的keepalive选项,这样双方还能检测及对方主机崩溃,或者崩溃然后又启动。

4:客户方所有应用这个服务器文件系统的应用程序共享斯TCP连接。例如,在觊觎29-6饱受,如果以bsdi的/usr目录下还来其他一个目录smith,那么对个别独目录/nfs/bsdi/usr/rstevens和/nfs/bsdi/usr/smith下有所文件之援将共享同样的TCP连接。

5:如果客户检测及服务器就倒,或者崩溃然后更启动(通过接收一个TCP差错“连接超时”或者“对方复位连接”),它尝试与服务器又成立连接。客户做另外一个能动打开,为同一个文件系统请求又建TCP连接。在原先老是达跨时的具有客户要于初的连年达都见面重新发。

6:如果客户机崩溃,那么当她崩溃时正运作的应用程序也要崩溃。当客户机重新启航时,它很可能以TCP重新安装服务器的文件系统,这将招致与服务器的其余一个连。客户及服务器之间针对同一个文件系统的前头一个一连现在打开了一半(服务器方认为它们还开始在),但是既然服务器设置了keepalive选项,当服务器发下一个keepalive探查报文时,这个半初步在的TCP连接就会于中止。

乘势时光之蹉跎,另外有厂商也计划支持TCP上之NFS。

29.6 NFS实例

俺们采取tcpdump来拘禁一下每当典型的文件操作着,客户调用了何等NFS过程。当tcpdump检测及一个含有RPC调用(在图29-1受调用字段等于0)、目的端口是2049之UDP数据报时,它将数据报按照一个NFS请求进行解码。类似地,如果一个UDP数据报是一个RPC应答(在祈求29-2着许诺答字段为1),源端口是2049,tcpdump就将这个数额报作为一个NFS应答来解码。

29.6.1 简单的例证:读一个文件

先是个例证是采取cat(1)命令将在一个NFS服务器上的一个文本复制到极限上:

似图29-6所出示,主机sun(NFS客户机)上的文件系统/nfs/bsdi/usr实际上是主机bsdi(NFS服务器)上的/usr文件系统。当cat打开这文件时,sun上之水源检测及马上一点,然后采用NFS去做客文件。图29-7著了tcpdump的输出。

当tcpdump解析一个NFS请求或承诺答报文时,它打印客户之XID字段,而无是端口号。第1实施和第2实施吃之XID字段值是0x7aa6。

客户基本中之打开函数一不行拍卖文件名/nfs/bsdi/usr/rstevens/hello.c中之一个分子。当处理到/nfs/bsdi/usr时,它发现立即是因于一个早已设置的NFS文件系统的一个安装点。

每当第1实行遭,客户调用GETAT
TR过程得客户就安装的服务器目录的习性(/usr)。这个RPC请求,除IP首部和UDP首部之外,包含104独字节的数目。第2执中之回复返回了一个OK值,除了IP首部和UDP首部之外,包含了96独字节的数据。在这图中,我们得望最小之NFS报文包含大约100独字节的数目。

图29-7 读一个文本之NFS操作

在第3实行遭,客户调用LOOKUP过程来查rstevens文件。在第4履行中收受一个OK应答。LOOKUP过程说明了文件名rstevens和长距离文件系统被装置时由于基本保存之公文句柄。应答中富含了产同样步而动的一个新的文本句柄。

在第5实践中,客户使用第4履遭回到的文书句柄对hello.c调用LOOKUP过程。在第6行返回了其余一个文本句柄。新的文本句柄就是客户以第7执行和第9实施遭援引文件/nfs/bsdi/usr/rstevens/hello.c所祭的文本句柄。我们来看客户对于正打开的程径名的每个成员还调用了同等涂鸦LOOKUP过程。

在第7实践遭,客户同时调用了同次GETAT
TR过程,接着在第9尽被调用了READ过程。客户要从偏移0开始之1024只字节,但是接受到之莫这么多(减去RPC字段和外由READ过程返回的价的轻重缓急,在第10执中回到了38单字节的数。这是文本hello.c的实际尺寸)。

在这个事例中,应用进程对于基本所开的这些RPC请求和应一点儿吗无懂得。应用进程只是调用了基石的open函数,后者引起了3个RPC请求与3单应答(16行),然后应用进程又调用了内核的read函数,它引起了两个请求和两个应答(710实行)。该文件在一个NFS文件服务器,这同点对客户使用进程来说是晶莹的。

29.6.2 简单的事例:创建一个目

当任何一个概括的事例,我们将当前工作目录改变吧一个晚创造一个初的目:

图29-8显示了tcpdump的输出。

图29-8 NFS的操作:cd到NFS目录,然后mkdir

变动目录引起客户调用了少于不良GETATTR过程(1~4行)。当我们创建新的目时,客户调用了GETAT
TR过程(56行),接着调用LOOKUP过程(78履行,用来证实将创造的目录不设有),跟着调用了MKDIR过程来创造目录(9-10履)。在第8执吃,应答OK并无代表目录在。它只是代表经过返回了。tcpdump并无知底NFS过程的归来值。它一般打印OK和应对报文中数量的字节数。

29.6.3 无状态

NFS的一个特性(NFS的批评者称之为NFS的一个瑕疵,而无是一个表征)是NFS服务器是任状态的(stateless)。服务器并无记录哪个客户在访问哪个文件。请小心一下以面前为出底NFS过程被,没有一个open操作与一个close操作。LOOKUP过程的效益跟open操作有些看似,但是服务器永远为不会见清楚客户对一个文件调用了LOOKUP过程后是否会见引用该文件。
任状态统筹的理是以以服务器崩溃而再启动时,简化服务器的夭折恢复操作。

29.6.4 例子:服务器崩溃

以底下的例子中我们从一个崩溃然后重新启动之NFS服务器上宣读一个文书。这个例子演示了不管状态的服务器是怎么令客户无知底服务器的倒台。除了在服务器崩溃然后再度启动时一个日子达之暂停外,客户并不知道发生的题材,客户以进程没有被震慑。

在客户机sun上,我们针对一个丰富文件(NFS服务器主机svr4上的文本/usr/share/lib/termcap)执行cat命令。在传递过程中管以太网的网线拔掉,关闭然后再启动服务器主机,再重将网线连上。客户于安排成每个NFS
read过程读1024独字节。图29-9著了tcpdump的出口。

1~10推行针对许给客户打开文件,操作看似于图29-7所展示。在第11实施我们看来对文本之率先单READ操作,在12履返回了1024只字节的数目。这个操作一直持续到129行(读1024单字节的数额,跟着一个OK应答)。

以第130行和第131行我们看来个别独请求过,并且分别以132行及133履行重传。第一只问题是此处为何会生出零星独读请求,一个打皇65536发端读,另一个于皇73728起来读?答案是客户基础检测及客户使用进程正在进行逐一地读操作,所以计算预先取得数据块(大多数底Unix内核都采用了这种预读技术)。客户基础也正在运行多独NFS块I/O守护程序,后者试图代表客户来多单RPC请求。一个护理程序在打皇65536处在读8192独字节(以1024字节呢平组数据块),而别一个在从73728介乎预读8192只字节。

客户重传发生在130~168尽。在第169尽我们来看服务器已还启动,在它对第168推行之客户NFS请求做出答复之前,它发送了一个ARP请求。对168实施的响应被发送在171实践。客户的READ操作继续拓展下。

除此之外由129实行及171实行5分钟之中止,客户以进程并不知道服务器崩溃然后以重新启动了。这个服务器的倒对于客户是晶莹底。

为研究是例子中之超时和重传时间距离,首先使发现及这时有少独客户守护程序,分别发出它分别的过。第1只守护程序(在舞狮65536处于起读)的区间,四放弃五顺应到零星只十向前制小数触及,为0.68,0.87,1.74,3.48,6.96,13.92,20.0,20.0,20.0等等。第2单守护程序(在摇摇73728处开始读)的区间也是一模一样的(精确到个别只小数点)。可以望这些NFS客户以了一个如此的超时定时器:间隔也0.875秒的翻番,上限为20秒。每次超时后,重传间隔翻倍:0.875,1.75,3.5,7.0暨14.0。

贪图29-9 当一个NFS服务器崩溃然后又启动时,客户在念一个文件之长河

客户若又污染多久呢?客户发出个别独与此有关的抉择项。首先,如果服务器文件系统是“硬”安装的,客户就见面永远重污染下来。但是要是服务器文件系统是“软”安装的,客户重传了永恒数目的次数之后便会放弃。在“硬”安装的动静下,客户还有一个取舍决定是否允许用户中断无界定的重传。如果客户主机安装服务器文件系统时说明了顿能力,并且使我们不思量以服务器崩溃后等5分钟,等正在服务器又启动,就得键入一个中断键以寝客户应用程序。

29.6.5 等覆盖过程

而一个RPC过程为服务器执行多次还返回同样的结果,那么即便将她让作当覆盖过程(Idempotent
Procedure)。例如,NFS的念过程是相当覆盖的。正像我们当祈求29-9遭到看看底,客户只是重发一个特定的READ调用直到它获一个响应。在我们的例证中,重传的原故是服务器崩溃了。如果服务器并未崩溃,而是RPC应答报文丢失了(既然UDP是不可靠的),客户只是重传请求,服务器又同不好实践同样的READ过程。同一个文书之同一部分被重复读一不善,发送给客户。
这种方式使得的原委在于每个READ请求指出了读操作起来的晃动位置。如果发一个NFS过程要求服务器读一个文本的下N个字节,这种方法就是颇了。除非服务器被做成是有状态的(与任状态相反),如果一个应对丢失了,客户重发读下N个字节的READ请求,结果用凡休雷同的。这就算是胡NFS的READ和WRITE过程要求客户说明开始的晃动位置的来由。客户维护在状态(每个文件时底摆位置),而不是服务器。

背的凡连无是具备的文件系统操作都是等覆盖的。例如,考虑下的动作:客户NFS发出REMOVE请求来删除一个文本;服务器NFS删除了文本,并回答OK;服务器的答疑丢失了;客户NFS超时,然后重传请求;服务器NFS找不顶指定的文书,回答指出一个错误;客户应用程序接收至一个错表示文件不存在。这个返回给客户应用程序的左是非正常的—该公文的确是而被删去了。

相当覆盖的NFS过程是:GETATTR、STATES、LOOKUP、READ、WRITE、READLINK和READDIR。不是相等覆盖的进程是:CREATE、REMOVE、RENAME、LINK、SYMLINK、MKDIR及RMDIR。SETATTR过程要无用来截断文件,一般是相等覆盖的。

既然如此用UDP总会发生应报文丢失的现象,NFS服务器需要同种植艺术来处理非等幂的操作。大多数底服务器实现了一个近年来应对的高速缓存,用于存放非等幂操作最近底回复。每当服务器收到一个请求,它首先检查是高速缓存,如果找到了一个匹配,就返回以前的对如不再调用相应的NFS过程。[Juszczak
1989]供了这种高速缓存的实现细节。

相当于覆盖服务器过程的定义可以行使为其它基于UDP的应用程序,而不只是NFS。例如,DNS也供了一个抵覆盖服务。一个DNS的服务器可以随心所欲多次地履一个解析者的请而并未其他不好的结果(如果非考虑网络资源浪费的言辞)。

29.7 第3版的NFS

1993年公布了第3版本的NFS协议正式[Sun Microsystem
1994]。其实现有望在1994年成为可能。

我们总一下第2本子与第3本的重大区别。下面将两者分别叫V2和V3。

1:V2中之文书句柄是32字节的一贯大小的数组。在V3中,它成为了一个尽多啊64独字节的可变长度的数组。在XDR中,一个只是更换长的数组被编码为一个4字节底数组成员个数跟着实际的数组成员字节。这样于实现时减少了文本句柄的尺寸,例如Unix只待12个字节,但与此同时允许非Unix实现保护另外的信息。

2:V2将每个READ和WRITE
RPC过程得读写的多寡限制为8192个字节。这个范围于V3中取消了,这虽象征一个UDP上的贯彻就受IP数据报大小的限定(65535字节)。这样允许以再次快的纱及宣读写更怪之分组。

3:文件大小以及READ和WRITE过程开始偏移的字节从32字节扩充到64字节,允许读写更甚之文本。

4:每个影响文件属性值的调用都回到文件之属性。这样减少了客户调用GETAT
TR过程的次数。

5:WRITE过程得是异步的,而以V2中求并的WRITE过程。这样好提高WRITE过程的性。

6:V3中去了一个历程(STAT
FS),增加了七单经过:ACCESS(检查文件访问权限)、MKNOD(创建一个Unix特殊文件)、READDIRPLUS(返回一个目中之文书名字与她的性质)、FSINFO(返回一个文件系统的静态信息)、FSSTAT(返回一个文件系统的动态信息)、PAT
HCONF(返回一个文书的POSIX.1信息)和COMMIT(将原先的异步写操作提交至外存中)。

29.8 小结

RPC是组织客户-服务器应用程序的一致种方式,使得看起客户只是调用了服务器的过程。所有的纱操作细节都于隐形在RPC程序包吗一个应用程序生成的客户及服务器残桩以及RPC库的例程中。我们展示了RPC调用和回答报文的格式,并且干了用XDR对传输的价进行编码,使得RPC客户及服务器可以运作于不同架构的机上。

顶广大应用的RPC应用之一就是是Sun的NFS,一个以各种大小的主机及大规模实现之异构的文本访问协议。我们浏览了NFS和它们用UDP和TCP的法。第2本子的NFS协议定义了15独过程。

一个客户对一个NFS服务器的走访开始受安协议,返回给客户一个文件句柄。客户就可以用非常文件句柄来访问服务器文件系统中之文书。在服务器上,一涂鸦检查文件称的一个成员,返回每个成员的一个初的文本句柄。最后之结果就是是要是引用的文件之一个文本句柄,它可以当随之的读写操作中为应用。

NFS试图把它们的所用经过还做成等覆盖的,使得如果响应报文丢失了,客户就待重发一个求。我们看出了服务器崩溃然后还要复启动时,一个客户读服务器上之一个文书之例证。

相关文章