ソース

https://wiki.wireshark.org/Network_Lock_Manager

目的

NLMプロトコルの目的は、にセマンティクスをロックPOSIX諮問ファイルのようなものを提供することである NFSのバージョン2と3のこのプロトコルは密接に結びついている NFSのそれが持つファイルハンドルのデータ構造共有しているため、プロトコル自体 NFSと、 NSMのどのプロトコルをロック・マネージャは、いくつかのプラットフォーム上で、ピアが再起動から回復するために使用し、 KLMのカーネルとユーザ空間ロックマネージャでNFSクライアント・コードとの間の通信に使用されるプロトコル。

NSM：ネットワークステータスの監視プロトコル

KLM：カーネルロック・マネージャ

動作位置

ロック・マネージャは、典型的に実装されているユーザー空間の内部に完全 ロック・マネージャ・デーモンに、

ワークス

ウィル・デーモンによってからのメッセージを受信NFSクライアントでロックが要求されたときにウィルによると、（ここでは、質問:? NLMデーモンは、NFSクライアントがサーバ、NFSサーバまたはサーバ上で実行されている）、NLMサーバーのNLMへの送信要求 ON NFSサーバマシン,,とインクルードは... ITが稼働しAPOSとローカルロックはこれらのクライアントに代わって呼び出しを行うするマシンのNFSクライアントからのNLM要求を受け取ることになりますあなたがクライアントとサーバーの両方で、このロック・マネージャデーモンを実行する必要があることにより、ロックする作業管理。（そう、デーモンはクライアント側とサーバー側を実行する必要があります）

NFSクライアントコードアットザカーネルの中によるロック・マネージャ・デーモンでと話をする別のプロトコルを使用します。たとえば、Sunの使用する可能性があります KLM ループバックインターフェイスに渡っプロトコル、またはケースにあるように、それはローカルの名前付きパイプ間で異なるプロトコルを使用する場合がありますいくつかのBSD。NFSクライアントのカーネルコードの（異なるOS上で、プロトコルは、例えば、SUNホストで命名を使用して、BSDカーネルながら、デーモン・パスと通信するKLMプロトコルループバックインタフェースを使用して、と通信するデーモンプログラムに与えられる異なるを使用し通信用パイプ）

歴史的起源

オリジナル盤でNLMプロトコルで後に来た NFS ザ・ステートフルプロトコルを必要とするより明らかにロックAS SunOSのサポートでバイト範囲ロックは、添加したとき。（NLMプロトコルは、SUNのオペレーティングシステムで提案されたので、後のバイト範囲ロックをサポートステートフルプロトコルは、ロック機構のために）必要不可欠ですのロックPOSIXスタイルのファイルを実装するためのプロトコルであるの目的で NFS サービスを。

4つの異なるバージョンがありました NLM 1〜3のバージョンは、すべてのクライアント（DOSとWindows用のリードPC-NFS）非UNIXを収容するためにバージョン2と3に追加された余分な機能の例外ではと実質的に同一である、プロトコル。THESE全ては、バージョン2つのバージョンは、 NFS（四つの異なるバージョンがありNLMプロトコルが、バージョン2は、図3に示すように、同一とみなすことができるすべてのサポートNFS V2）。

NFS V3は、構造が時に書き込みを変更したときように、NFS共有構造のNLMので、NLMは、同時リリースバージョンV3を持っていました。

NLMプロトコルが除去され、中にNFS V4では、すべてのロック機構は、NFSv4の契約内に直接実装されています。

NLMプロトコルの問題自体は、しばしばによって引き起こされています：

ファイルがロックされることはありません（クライアントがロックを解除し忘れたとき）、解放することができません
cliengライブハング
（同時に排他ロックが保持している文書に2つのプロセスが場合に）破損ファイル

多くの場合、上記の状況からフィールドがそのようなそのようなONの再送信や並べ替えパケットネットワークASこれらの正常かつシンプルな物事をシンプルに結果。
多くはfcntlのは、使用して簡易ファイルのファイルを呼び出し、ロックファイルロックINSTEADに頼るのしたがって、独自のスタイルファイルアプリケーションそのアプリケーションの実装、多くの場合、フィールドの.lockを参照のこと。（前述の問題が原因で知られている、のfcntlロックを生成するのではなく、アプリケーション層で実装されたロックを好む多くのアプリケーション）のファイル

NLM支援機能インタフェース

ヌル、テスト、ロック、ロック解除、キャンセルと確かに：PC-NFSやその他の非UNIXクライアントのために追加の特別な機能については忘れて、このプロトコルは、わずか6つの機能を実装しています。

ヌル：この機能の標準的な「ピング」機能で 、すべての ONC-RPCのサービスを使用し、単にそれが健在であることを確認するためには「ピング」サービスに使用されます。
テスト：この関数は、ロック要求が成功するか否ならば、「テスト」に使用されることを意図していました。 サーバー上のロック状態は、多くの場合、テストコールが完了したときの間、クライアントに到達する応答の前に変更されることができますので、これは実際に有用ではありません。いいえクライアントの実装は、これまで、この機能を使用しません。
ロック：この機能は、サーバー上で取り出すことにするロックを要求するために使用されます。排他ロック要求のロック競合のための要求の場合に発生する可能性があります（他の誰かがすでにファイルのロックを持っている）とロックがクライアントに付与することはできません。だけではなく、ロックをAQUIREに失敗したことを報告し、クライアントがロックをポーリングを継続的にするので、サーバーは、ここでロックが今付与することができないことをクライアントに伝える、BLOCKED応答で応答しますが、そのサーバーが実行されますバッククライアントへのコールバックを許可されたロックが使用可能で、クライアントに割り当てられているとき。（クライアントがロックを要求し、ロックがすでに別のクライアントによって保持されている、NLMはラフ失敗を返しませんが、コールバック関数が含まれているBLOCKEDへの応答を返します。NLMサーバがロックを取得することができた場合、ロックするときクライアントに割り当てることができたときに、それが付与されたメッセージは、それがブロックされたロックが付与されてhasnt場合、クライアントはまだ元の要求を再送する理由は、ネットワーク上で失われてしまうことに注意してください）コールバック関数を呼び出します一度10または20秒ロックは通常、非常に短命なので、それはブロックする要求に遭遇したとき、またはそう。、多くのサーバは、ロックが後でいつか利用可能になっている場合がありますので、全体がブロックされていること日和見前提にいくつかのミリ秒のロック要求の実行を延期しますそして、付与されたハンドシェイクが短絡されます。
ロック解除：この機能は、サーバーに戻す開催された（またはブロック）されたロックを解除します。
キャンセル：この関数は、ロックを解除するために同一であり、多くの実装は、ちょうどとにかくロック解除関数を呼び出す簡単なスタブ関数であってもキャンセルしています。：ネットワークを分析する人々のために、これらの機能は、実際に異なり、追加情報を提供しないトレースアプリケーションが明示的にfcntl（）の呼び出しによって、ロックを解除されたときに通常使用されているロックを解除します。アプリケーション自体の後にロックをクリーンアップせずに終了した後にキャンセルは通常、ロックマネージャによって発行されます。すなわちキャンセルは、ロックを保持しているアプリケーションが終了していると、それが割り当てられたリソースをクリーンアップされたカーネルにおけるVFS層であることを意味する。（在实际功能上是一样的、但适用的场景略有差异キャンセル和アンロック）
確かに：この機能は、サーバーによって使用される ブロックされたロックが使用可能になっており、それがロックを必要としていることを知らせるために戻って、クライアントへの呼び出しを行うために使用されている場合。

冪等

冪等するためには、実装はすなわち、実行-で最大1回のセマンティクスを実装、すべての重複の要求に同じ応答で応じなければなりません。再送の存在下で、これは少し、このプロトコルには影響を与えず、すべての実装がこの権利を持っているではありません。 これは、機能のための応答コードがわずかにその意味を変更することを意味し、これを確認する最も簡単な方法は、コールが、状態遷移が実際に発生したかどうかを完了していなかった後に、サーバー上の結果の状態を記述した応答コードを持つようです。呼び出しが完了した後、ロックはロックのdidntは、コールが無関係で開始された前でさえも存在すること、存在しないため、サーバーは、まだ成功したロック解除で応答します：1が存在していないロックのロック解除要求を送信した場合これは見ることができます。

いくつかのクライアント実装は、サーバに問題を引き起こすべき等されていません。特に、いくつかのSolaris以外のレガシーUNIX実装が付与コールで冪等されていない状態遷移が発生したか否かに応じて、異なる応答コードを返します。サーバは常に許可呼び出しに完全に応答コードを無視し、成功と任意およびすべての応答を処理することにより、この問題を回避します。

同期、非同期VS

両方が同じ機能を提供NLMの2つのスタイルがあります。同期および非同期。ほとんどすべての実装は、同期バージョンを使用していますが、HP-UXなど一部の古いレガシーunixenは、非同期バージョンを使用して行います。主な違いは、同期NLMが正常であることである ONC-RPC 非同期バージョンは、メッセージ/メッセージ・プロトコルであるが、要求/応答プロトコル。

NLMの非同期バージョンではどんな存在しなくなります ONC-RPCの代わりにNLM応答は次のように送り返され、層の応答 ONC-RPCの要求メッセージ。これがあることを意味 ONC-RPCのトランザクションID（XID）が「レスポンス」と「要求」を一致させるために使用することはできません、またXIDは、潜在的な再送を検出するために使用することができます。代わりに、すべてのNLM PDUの初めにクッキーフィールドは、要求と応答を一致させるために使用されます。このクッキーフィールドは、NLMの同期バージョンにも存在するが、そこには意味論的な意味を持ちません。Wiresharkのは、Wiresharkのは、クッキーに基づく応答と要求と一致できるようにすることができます好みの設定を持って、この設定はデフォルトではオフになっています。

また、読書：

4.1 NLMロック複数のNFSサーバー間

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

ネットワークロックマネージャプロトコル（NLM）