Glusterfs之nfs模块源码分析文档格式.docx
《Glusterfs之nfs模块源码分析文档格式.docx》由会员分享,可在线阅读,更多相关《Glusterfs之nfs模块源码分析文档格式.docx(21页珍藏版)》请在冰豆网上搜索。
proc;
opaque_auth
cred;
verf;
1
parameter
2
parameter
.
};
答复信息:
协议的答复信息的改变取决于网络服务器对调用信息是接收还是拒绝。
答复信息请求包括区别以下情形的各种信息:
成功执行调用信息。
.
RPC
的远程实现不是协议第二版,返回
支持的最低和最高版本号。
在远程系统中,远程程序不可用。
远程程序不支持被请求的版本号。
返回远程程序所支持的最低和最高版本号。
请求的过程号不存在。
通常是呼叫方协议或程序差错。
RPC答复信息形式如下:
enum
reply_stat
stat
{MSG_ACCEPTED
=
0,
MSG_DENIED
1
第三节、工作原理
运行时,一次客户机对服务器的RPC调用,其内部操作大致有如下十步:
1.调用客户端句柄;
执行传送参数
2.调用本地系统内核发送网络消息
3.消息传送到远程主机
4.服务器句柄得到消息并取得参数
5.执行远程过程
6.执行的过程将结果返回服务器句柄
7.服务器句柄返回结果,调用远程系统内核
8.消息传回本地主机
9.客户句柄由内核接收消息
10.客户接收句柄返回的数据
第四节、RPC
OVER
HTTP
Microsoft
RPC-over-HTTP
部署(RPC
over
HTTP)允许RPC
客户端安全和有效地通过Internet
连接到RPC
服务器程序并执行远程过程调用。
这是在一个名称为RPC-over-HTTP
代理,或简称为RPC
代理的中间件的帮助下完成的。
代理运行在IIS
计算机上。
它接受来自Internet
的RPC
请求,在这些请求上执行认证,检验和访问检查,如果请求通过所有的测试,RPC
代理将请求转发给执行真正处理的RPC
服务器。
通过RPC
HTTP,RPC
客户端不和服务器直接通信,它们使用RPC
代理作为中间件。
Glusterfs之nfs模块源码分析(下)之NFS协议之RPC的实现和NFS协议内容
六、NFS协议之RPC的实现
因为nfs服务器启动时的端口是不确定的,所以nfs服务器将自己的端口注册到rpc服务,客户端通过rpc请求知道nfs服务器的监听端口。
下面就分析整个rpc的处理过程。
现在假设客户端有一个rpc请求达到服务器端了,通过上面nfs协议初始化的分析知道:
所有的数据读写事件都是在函数nfs_rpcsvc_conn_data_handler中处理,因为是客户端发送来的请求数据,所以执行的是epoll_in事件处理相关代码,这些事件的处理都是在函数nfs_rpcsvc_conn_data_poll_in中,这个函数实现如下:
1intnfs_rpcsvc_conn_data_poll_in(rpcsvc_conn_t*conn)
2
3{
4
5ssize_tdataread=-1;
6
7size_treadsize=0;
8
9char*readaddr=NULL;
10
11intret=-1;
12
13readaddr=nfs_rpcsvc_record_read_addr(&
conn->
rstate);
//rpc服务记录开始读取数据的地址
14
15readsize=nfs_rpcsvc_record_read_size(&
//rpc服务记录数据需要读取的长度
16
17dataread=nfs_rpcsvc_socket_read(conn->
sockfd,readaddr,readsize);
//从socket中读出记录数据
18
19if(dataread>
0)
20
21ret=nfs_rpcsvc_record_update_state(conn,dataread);
//根据读取的数据处理
22
23returnret;
24
25}
上面代码首先会根据rpc服务记录中的接收数据类型来判断接收什么数据,主要是分为头部消息和正式的rpc消息,正式的rpc消息的长度是通过头部消息中给出的,所以接收消息的步骤一般是先头部消息,然后正式的rpc调用消息,否则就是视为错误的消息,然后根据消息的长度从socket中读出消息到rpc服务记录的结构体的成员变量中,最后交给函数nfs_rpcsvc_record_update_state处理,它根据读取的数据来处理整个rpc的过程,包括xdr(外部数据表示)和根据消息获取调用的函数并且执行函数,具体实现如下:
1intnfs_rpcsvc_record_update_state(rpcsvc_conn_t*conn,ssize_tdataread)
5rpcsvc_record_state_t*rs=NULL;
7rpcsvc_t*svc=NULL;
9rs=&
rstate;
11if(nfs_rpcsvc_record_readfraghdr(rs))//根据rpc服务的记录状态是否读取头部消息
13dataread=nfs_rpcsvc_record_update_fraghdr(rs,dataread);
//读取消息头部
15if(nfs_rpcsvc_record_readfrag(rs)){//是否读取后面的数据
17if((dataread>
0)&
&
(nfs_rpcsvc_record_vectored(rs))){//是否读取向量片段(
19dataread=nfs_rpcsvc_handle_vectored_frag(conn,dataread);
//处理向量片段数据
21}elseif(dataread>
0){
23dataread=nfs_rpcsvc_record_update_frag(rs,dataread);
//更新rpc服务记录的片段数据
25}
26
27}
28
29if((nfs_rpcsvc_record_readfraghdr(rs))&
(rs->
islastfrag)){//如果下一条消息是头部消息且是最后一帧
30
31nfs_rpcsvc_handle_rpc_call(conn);
//处理rpc调用
32
33svc=nfs_rpcsvc_conn_rpcsvc(conn);
//链接对象引用加1
34
35nfs_rpcsvc_record_init(rs,svc->
ctx->
iobuf_pool);
//重新初始化rpc服务记录的状态信息
36
37}
38
39return0;
40
41}
整个函数首先读取协议信息的头部消息,读取完头部信息以后更新rpc服务记录状态,然后根据更新的状态继续读取头部信息后面的消息,后面的消息分为两种情况来读取,一般第一次来的是一个头部消息,这个消息中记录了下一次需要读取的消息的长度,也就是正式的rpc调用信息的长度。
所以当第二次消息响应来的时候就是正式消息,根据不同的消息有不同的处理方式。
头部消息处理方式主要是为接收正式的消息做一些初始化和准备工作(例如数据的长度和类型等)。
如果头部消息则不会执行处理rpc的调用函数,因为它必须要接收到rpc调用消息以后才能处理。
下面继续分析处理rpc调用的函数nfs_rpcsvc_handle_rpc_call,因为它是处理整个rpc调用的核心,它的实现如下:
1intnfs_rpcsvc_handle_rpc_call(rpcsvc_conn_t*conn)
5rpcsvc_actor_t*actor=NULL;
7rpcsvc_request_t*req=NULL;
9intret=-1;
11req=nfs_rpcsvc_request_create(conn);
//动态创建一个rpc服务请求对象(结构体)
13if(!
nfs_rpcsvc_request_accepted(req))//是否接受rpc服务请求
15;
17actor=nfs_rpcsvc_program_actor(req);
//得到rpc服务调用过程的描述对象
19if((actor)&
(actor->
actor)){
21THIS=nfs_rpcsvc_request_actorxl(req);
//得到请求的xlator链表
23nfs_rpcsvc_conn_ref(conn);
//链接状态对象的引用加1
25ret=actor->
actor(req);
//执行函数调用
29returnret;
31}
这个函数首先根据链接状态对象创建一个rpc服务请求的对象,然后根据rpc服务请求对象得到一个rpc服务调用过程的描述对象,最后就根据这个描述对象执行具体的某一个rpc远程调用请求。
下面在看看怎样根据连接状态对象创建rpc服务请求对象的,nfs_rpcsvc_request_create函数实现如下:
1rpcsvc_request_t*nfs_rpcsvc_request_create(rpcsvc_conn_t*conn)
5char*msgbuf=NULL;
7structrpc_msgrpcmsg;
9structiovecprogmsg;
/*RPCProgrampayload*/
11rpcsvc_request_t*req=NULL;
13intret=-1;
15rpcsvc_program_t*program=NULL;
17nfs_rpcsvc_alloc_request(conn,req);
//从内存池中得到一个权限请求对象并且初始化为0
19msgbuf=iobuf_ptr(conn->
rstate.activeiob);
//从激活的IO缓存得到一个用于消息存放的缓存空间
21//从xdr数据格式转换到rpc数据格式
23ret=nfs_xdr_to_rpc_call(msgbuf,conn->
rstate.recordsize,&
rpcmsg,
25&
progmsg,req->
cred.authdata,req->
verf.authdata);
27nfs_rpcsvc_request_init(conn,&
rpcmsg,progmsg,req);
//根据上面转换的消息初始化rpc服务请求对象
29if(nfs_rpc_call_rpcvers(&
rpcmsg)!
=2){//rpc协议版本是否支持
31;
33}
35ret=__nfs_rpcsvc_program_actor(req,&
program);
//根据程序版本号得到正确的rpc请求描述对象
37req->
program=program;
39ret=nfs_rpcsvc_authenticate(req);
//执行权限验证函数调用验证权限
41if(ret==RPCSVC_AUTH_REJECT){//是否被权限拒绝
42
43;
44
45}
46
47returnreq;
48
49}
通过上面的函数调用就得到了一个正确版本的rpc服务远程调用程序的描述对象,后面会根据这个对象得到对应的远程调用函数的描述对象,这个是通过下面这个函数实现的:
1rpcsvc_actor_t*nfs_rpcsvc_program_actor(rpcsvc_request_t*req)
5interr=SYSTEM_ERR;
7rpcsvc_actor_t*actor=NULL;
9actor=&
req->
program->
actors[req->
procnum];
//根据函数id得到正确的函数调用对象
11returnactor;
13}
这里得到的函数调用对象就会返回给调用程序,调用程序就会具体执行远程过程调用了。
到此一个完整的rpc调用以及一个nfs服务就完成了,nfs服务器就等待下一个请求,整个过程可谓一波三折,整个过程绕了很大一个圈。
下面通过一个图来完整描述整个过程:
附件1
NFS
Protocol
Family
The
protocol
suite
includes
the
following
protocols:
MNTV1
Mount
1,
for
2
Mntv3
3,
3
NFS2
Network
File
system
NFS3
NFSv4
4
NLMv4
Lock
Manager
NSMv1
Status
Monitor
protocol
MNTV1:
ftp:
//ftp.rfc-editor.org/in-notes/rfc1094.txt.
2
(MNTv1)
is
separate
from,
but
related
to,
protocol.
It
provides
operating
specific
services
to
get
off
ground
--
looks
up
server
path
names,
validates
user
identity,
and
checks
access
permissions.
Clients
use
first
file
handle,
which
allows
them
entry
into
a
remote
filesystem.
kept
from
make
it
easy
plug
in
new
checking
validation
methods
without
changing
protocol.
Notice
that
definition
implies
stateful
servers
because
maintains
list
of
client'
s
mount
requests.
information
not
critical
correct
functioning
either
client
or
server.
intended
advisory
only,
example,
warn
possible
clients
when
going
down.
Version
one
used
with
two
only
communicated
between
these
protocols
"
fhandle"
structure.
header
structure
as
follows:
8
7
6
5
1
Octets
Directory
Path
Length
Name
5-N
Length:
directory
length.
Name:
name.
Mntv3:
//ftp.rfc-editor.org/in-notes/rfc1813.txt.
supporting
3
performs
system-specific
functions
allow
attach
trees
point
within
local
system.
process
also
grant
privileges
restricted
set
via
export
control.
support
locking
environment.
(NLM)
isolates
inherently
aspects
A
complete
description
above
their
implementation
be
found
[X/OpenNFS].
normative
text
procedures
arguments
results,
defines
over-the-wire
protocol,
semantics
those
procedures.
material
describing
practice
aids
understanding
specification
describes
some
issues
solutions.
describe
all
implementations
UNIX
most
often
provide
examples.
follows.
length:
name
NFS2:
//ftp.rfc-editor.org/in-notes/rfc1