资料来源

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协议本身常常会造成的问题有:

  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

Network Lock Manager Protocol (NLM)的更多相关文章

  1. distributed lock manager (DLM)(分布式管理锁)

    A distributed lock manager (DLM) provides distributed software applications with a means to synchron ...

  2. FreeBSD_11-系统管理——{Part_4 - 内核参数定制}

    特别提醒:自行定制的内核,必須经过全方位测试无誤后,方能用于生产环境 基于:/usr/src/sys/amd64/conf/GENERIC cpu HAMMER ident TEST_kernel # ...

  3. 第3章 NFS基本应用

    1.1 概述 类似ext家族.xfs格式的本地文件系统,它们都是通过单个文件名称空间(name space)来包含很多文件,并提供基本的文件管理和空间分配功能.而文件是存放在文件系统中(上述名称空间内 ...

  4. pythonic context manager知多少

    Context Managers 是我最喜欢的 python feature 之一,在恰当的时机使用 context manager 使代码更加简洁.清晰,更加安全,复用性更好,更加 pythonic ...

  5. [network] IPVS / Load balancer / Linux Virtual Server

    Load Balancer IPVS: http://kb.linuxvirtualserver.org/wiki/IPVS NAT: http://kb.linuxvirtualserver.org ...

  6. Internet protocol optimizer

    A method for optimizing the throughput of TCP/IP applications by aggregating user application data a ...

  7. Heterogeneous Self-Organizing Network for Access and Backhaul

    This application discloses methods for creating self-organizing networks implemented on heterogeneou ...

  8. Overlay network 覆盖网络

    From Wikipedia, the free encyclopedia An overlay network is a computer network that is built on top ...

  9. tcp protocol number

    在计算机网络OSI模型中,TCP端口完成第四层传输层所指定的功能.我们的电脑与网络连接的许多应用都是通过TCP端口实现的.本文与大家分享部分TCP端口的介绍. 21端口:21端口主要用于FTP(Fil ...

随机推荐

  1. Python决策树可视化:GraphViz's executables not found的解决方法

    参考文献: [1]Python决策树可视化:GraphViz's executables not found的解决方法

  2. SQL注入中的WAF绕过

    1.大小写绕过 这个大家都很熟悉,对于一些太垃圾的WAF效果显著,比如拦截了union,那就使用Union UnIoN等等绕过. 2.简单编码绕过 比如WAF检测关键字,那么我们让他检测不到就可以了. ...

  3. Android Studio在代码重构中的妙用

    代码重构几乎是每个程序员在软件开发中必须要不断去做的事情,以此来不断提高代码的质量.Android Stido(以下简称AS)以其强大的功能,成为当下Android开发工程师最受欢迎的开发工具,也是A ...

  4. js动画--缓冲动画

    前面讲述的动画速度都是匀速的,现实生活中的运动速度的变化不一定是恒定的,存在一定的缓冲,就像火车进站一样,速度会越来越慢. 对于改变速度措施,其实只要将动画第一课的程序稍微的改变一下就可以了,我们来看 ...

  5. 20180606模拟赛T1——猫鼠游戏

    题目描述: 猫和老鼠在10*10的方格中运动,例如: *...*..... ......*... ...*...*.. .......... ...*.C.... *.....*... ...*... ...

  6. WebRTC中的NetEQ

    NetEQ使得WebRTC语音引擎能够快速且高解析度地适应不断变化的网络环境,确保了音质优美且缓冲延迟最小,其集成了自适应抖动控制以及丢包隐藏算法. WebRTC和NetEQ概述 WebRTC Web ...

  7. Codeforces Round #552 (Div. 3)-1154E-Two Teams-(模拟+双指针)

    http://codeforces.com/contest/1154/problem/E 解题: 举例n=10,k=1 1,2,10,4,7,6,9,8,5,3 第一次,1队先挑2,10,4这三个人 ...

  8. bzoj 3992: [SDOI2015]序列统计 NTT+原根

    今天开始学习丧心病狂的多项式qaq......    . code: #include <bits/stdc++.h> #define ll long long #define setIO ...

  9. 交叉引用:Microsoft.NET标准异常 和错误代码对照表

    简介 此表旨在帮助将Windows运行时应用程序错误代码交叉引用到Microsoft.NET标准异常,这些异常可以作为应用程序异常处理技术的一部分. 对照表 .NET Exception (Names ...

  10. 洛谷 P1195 【口袋的天空】

    P1195 传送门 大体题意: 就是给你\(n\)个点\(m\)条边, 然后让你把这几个点连成\(k\)个部分. 解题思路: 很容易就可以想到生成树(别问我怎么想到的). 因为最小生成树中有一个判断 ...