资料来源
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个不同的版本，但版本1、2、3可视为同一个，都是对NFS V2的支持）
由于NLM跟NFS共用结构体，因此，当NFS V3中，将Write结构体变更时，NLM不得不同步发行v3版本。
而在NFS V4中，NLM协议被移除了，所有的锁机制均直接实现在NFSV4协议内部。
NLM协议本身常常会造成的问题有：
- 文件被永远锁住，无法释放（client忘记释放锁时）
- clieng hang住
- 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.
延伸阅读：
http://people.redhat.com/rpeterso/Project/nlmlockacrossmultiplenfsservers