Gluster Source code reading 1--RPC and NFS

Gluster is essentially an NFS (Network file System), and NFS is interpreted as follows (excerpt from the network)

In 1984, Sun Microsystems introduced a widely accepted remote file access mechanism in the entire computer industry, known as the Sun's network file system, or simply as NFS. This mechanism allows you to run a server on one computer, allowing remote access to some or all of the files on it, and allowing applications on other computers to access the files. It enables us to achieve file sharing. When users want to use the remote file as long as the "mount" can be connected to the remote file system under their own file system, so that the remote files on the operation and the local machine files are no different. An application can open (open) a remote file for access, read (read) data from this file, write data to the file, locate (Seek) to a specified location in the file (start, end, or elsewhere), and then close when the use is complete ( Close) the file. And these operations are transparent to the programmer, and the operation method is exactly the same as for local files. NFS is a client/server application constructed using SUNRPC, whose clients access files by sending RPC requests to an NFS server NFS is a client/server application constructed using SUNRPC. Its client accesses files in it by sending an RPC request to an NFS server

The diagram is as follows

As you can see from the image above, RPC is kernel-based, and one of the most obvious benefits of kernel-based is that there is less switching between the user and kernel states, because the switch is to copy the data

However, the gluster is not using the NFS service that comes with the operating system, it writes its own RPC service based on the NFS standard, and listens to the RPC service using the NFS default listener port 2049来, which will be introduced in subsequent chapters Gluster RPC and Gluster NFS

In the Gluster, the server responds to requests from the client using RPC servers, and the client uses the RPC client to send the request, so all traffic is RPC-based.

However, RPC and NFS are 2 separate components, but they are also inseparable, so before NFS starts, make sure that RPC starts first, for the following reasons: (excerpt from Network http://vbird.dic.ksu.edu.tw/linux_server/0330nfs.php):

NFS supports quite a lot of features, and different functions are started with different programs, and each boot feature will enable some ports to transfer data, so the Port for NFS is fixed, but this will cause the client to have trouble connecting to the server, Because the client needs to know the server side of the relevant end of eloquence can be online.

At this point we need a remote procedure call (RPC) service. The main function of RPC is to specify the port number for each NFS function and return it to the client so that the client can connect to the correct port. And how does RPC know each NFS port? This is because when the server starts NFS, it randomly takes several ports and actively registers with RPC, so RPC can know the NFS function for each port, and then RPC uses PORT111 to listen to the client's demand and return the correct port for the client.

When the client has an NFS file to access the request, how it requests data to the server side.

1. The client issues an NFS file access request to the server-side RPC (Port 111).

2, the server side found the corresponding registered Nfsdaemon port will be returned to the client.

3. After the client knows the correct port, it can be brought online directly with the NFS daemon.

So the entire protocol stack looks like this:

Nfs

XDR (Note 1)

Rpc

Tcp,udp

Ip

DataLink

Ethernet

Note 1:xdr (Externaldata representation, or external data representation) provides a way to convert data from one format to another standard data format notation, ensuring that all data represents the same meaning in different computer, operating system, and programming languages

You can use Rpcinfo to get the registered RPC