Network Lock Manager Protocol (NLM)

資料來源

https://wiki.wireshark.org/Network_Lock_Manager

目的

The purpose of the NLM protocol is to provide something similar to POSIX advisory file locking semantics to NFS version 2 and 3. This protocol is closely tied with the NFS protocol itself since it shares the file handle data structure with NFS, with the NSM protocol which the lock manager uses to recover from peer restarts, and, on some platforms the KLM protocol which is used to communicate between the NFS client code in the kernel and the user space lock manager.

NSM： Network Status Monitoring Protocol

KLM：Kernel Lock Manager

運行位置

The lock manager is typically implemented completely inside user space in a lock manager daemon;

工做原理

that daemon will receive messages from the NFS client when a lock is requested, （疑問：此處的NLM daemon是運行在nfs client服務器上的，仍是nfs server服務器上的？）and will send NLM requests to the NLM server on the NFS server machine, , and will receive NLM requests from NFS clients of the machine on which it's running and will make local locking calls on behalf of those clients.. You need to run this lock manager daemon on BOTH the client and the server for lock management to work. （因此，daemon是須要在client和server端都運行的）

The NFS client code in the kernel will use a different protocol to talk to the lock manager daemon; for example, it might use Sun's KLM protocol across the loopback interface, or it might use a different protocol across a local named pipe as is the case on some BSDs.（不一樣OS的NFS client內核代碼，會使用不一樣給的協議來與daemon程序通訊，例如在SUN主機中，使用KLM協議經過迴環接口與daemon通訊，而在BSD 內核中，則使用命名管道進行通訊）

歷史由來

The NLM protocol came after the original release of NFS when byte-range locking support was added in SunOS, as locking more obviously requires a stateful protocol. （NLM 協議是在SUN操做系統支持byte-range locking後被提出的，由於一個有狀態的協議對鎖機制來講相當重要）The purpose of the protocol is to implement POSIX-style file locking for NFS services.

There has been 4 different versions of the NLM protocol, versions 1 to 3 are all virtually identical with the exception of extra functions being added to version 2 and 3 to accomodate non-UNIX (read PC-NFS for DOS and Windows) clients. These versions are all for version 2 of NFS. （NLM協議共有4個不一樣的版本，但版本一、二、3可視爲同一個，都是對NFS V2的支持）

因爲NLM跟NFS共用結構體，所以，當NFS V3中，將Write結構體變動時，NLM不得不一樣步發行v3版本。

而在NFS V4中，NLM協議被移除了，全部的鎖機制均直接實如今NFSV4協議內部。

NLM協議自己經常會形成的問題有：

1. 文件被永遠鎖住，沒法釋放（client忘記釋放鎖時）
2. clieng hang住
3. file corruption（當兩個進程同時對一個文件持有排他鎖時）

These situations above often result from such normal and simple simple things such as retransmissions or packet reordering on the network.
Many applications therefore implement their own application style file locking instead of relying on the file locking fcntl calls using simple files, often refered to .LOCK files（因爲上述的已知問題，不少應用程序寧願選擇在應用層實現一個鎖，而不是使用fcntl來生產鎖）

NLM支持的函數接口

Forgetting about the special functions added for PC-NFS and other non-UNIX clients, this protocol only implements 6 functions : Null, Test, Lock, Unlock, Cancel and Granted.

• Null : this functions is the standard "ping" function that all ONC-RPC services use, it is merely used to "ping" the service to see that it is alive and well.

• Test : This function was intended to be used to "test" if a lock request would succeed or not. This is not useful in reality since the lock state on the server can and often will change between when the test call completed and before the response will reach the client. No client implementations ever use this function.
• Lock : this function is used to request a lock to be taken out on the server. In case of a request for an exclusive lock request lock contention can occur (someone else already has a lock for the file) and the lock can not be granted to the client. Instead of just reporting a failure to aquire the lock and having the clients to continously poll for the lock, the server will here respond with a BLOCKED response, telling the client that the lock can not be granted right now but that the server will perform a Granted callback back to the client when the lock is available and has been assigned to the client. （當一個client請求鎖，而該鎖已經被其餘client持有時，NLM不會粗暴的返回一個fail，而是返回一個BLOCKED響應，裏面含有一個callback函數。當NLM server能夠得到鎖，而且該鎖能夠分配給這個client時，就會調用這個回調函數）Note that the Granted messages can become lost on the network which is why the clients will still retransmit the original request if it hasnt been granted a blocked lock once every 10 or 20 seconds or so. Since locks are usually very short lived, many servers will when it encounters a request that would block, postpone execution of the locking request for some miliseconds on the opportunistic assumption that the lock might have become available sometime later and thus the entire blocked and granted handshake will be short-circuited.
• Unlock : This function will release a lock that is held (or blocked) back to the server.
• Cancel : this function is identical to Unlock and many implementations have Cancel just be a simple stub function that just calls the Unlock function anyway. For people analyzing network traces these functions do actually differ and provide additional information : Unlock are usually used when the application is explicitly releasing a lock by the fcntl() call. Cancel is usually issued by the lock manager after the application has terminated without cleaning up the locks after itself. I.e. Cancel means the application holding the lock has terminated and it is the VFS layer in the kernel that is cleaning up the allocated resources.（unlock和cancel在實際功能上是同樣的，但適用的場景略有差別）
• Granted : This function is used by the server when a blocked lock has become available and is used to make a call back to the client to tell it that it has required the lock.

冪等性

In order to be idempotent, an implementation MUST respond with the same response to all duplicated requests, i.e. implement execute-at-most-once semantics. In presence of retransmissions this does affect this protocol slightly and not all implementations have got this right. This does mean that the response codes for the functions change their meaning slightly, the easiest way to see this is as having the response codes describing the resulting state on the server after the call has completed and not whether a state transition actually occured. This can be seen if one sends Unlock requests for locks that does not exist : the server will still respond with Unlock successful since the lock does not exist after the call completed, that the lock didnt exist even before the call was initiated is irrelevant.

Some client implementations are not idempotent which causes problems for servers. In particular some non-Solaris legacy unix implementations are not idempotent in the Granted call and return different response codes depending on whether the state transition occured or not. Servers work around this by always ignoring completely the response code to Granted calls and treating any and all responses as success.

同步 VS 異步

There are two styles of NLM which both provide the same functions; Synchronous and Asynchronous. While almost all implementations use the synchronous version, some older legacy unixen such as HP-UX do use the Asynchronous version. The main difference is that Synchronous NLM is a normal ONC-RPC request/response protocol while the asynchronous version is a message/message protocol.

In the asynchronous version of NLM there will not be any ONC-RPC layer responses, instead the NLM responses are sent back as ONC-RPC request messages. This means that the ONC-RPC transaction id (XID) can not be used to match "request" with "responses", nor can the XID be used to detect potential retransmissions. Instead, the cookie field in the beginning of every NLM PDU is used to match requests and responses. This cookie field is also present in the synchronous version of NLM but has no semantic meaning there. Wireshark has a preference setting which can allow Wireshark to match requests with responses based on the cookie, this preference is off by default.

延伸閱讀：

4.1 NLM Locks Across Multiple NFS Servers

http://people.redhat.com/rpeterso/Project/nlmlockacrossmultiplenfsservers