netconf に関する RFC6241 を読んでいました。そこでは、プロトコルのメッセージング メカニズムとしての RPC について書かれています。ただし、仕様では RPC メッセージを送信するための XML が定義されているため、なぜこれがまだ RPC と呼ばれているのかよくわかりません。私は RPC をONC RPCで説明されているように考えていました。つまり、スタブ関数が定義されている必要があります ( Unix ではrpcgenによって行われているように) などですが、NETCONF が言うことはこのパラダイムに厳密に従っているのではなく、送信するメカニズムを定義しています。パラメータをワイヤ経由で送信します。
おそらく、私は RPC を概念として誤解しています。だれか netconf の RPC を明確にしてくれませんか? ありがとう、
リモート プロシージャ コールの概念は、クライアントとサーバーの通信モデルにおける要求と応答のメカニズムを単純に抽象化したものです。クライアントは (リモート) サーバーに要求を送信し、応答を待ち、それを受信すると、受信した情報に基づいて実行を継続します。それだ。これは基本的に、NETCONF 操作を呼び出すときに発生することです。
あなたが引用した仕様：
ONC RPC プロトコルは、ローカル プロシージャ コール モデルに似たリモート プロシージャ コール モデルに基づいています。ローカルの場合、呼び出し元は、適切に指定された場所 (レジスタ ウィンドウなど) に引数をプロシージャに配置します。次に、制御をプロシージャに渡し、最終的に制御を取り戻します。その時点で、適切に指定された場所からプロシージャの結果が抽出され、呼び出し元は実行を継続します。
リモート プロシージャ コール モデルも同様です。制御の 1 つのスレッドは、2 つのプロセス (呼び出し元のプロセスとサーバーのプロセス) を論理的に通過します。呼び出し元は、最初に呼び出しメッセージをサーバー プロセスに送信し、応答メッセージを待機 (ブロック) します。呼び出しメッセージにはプロシージャのパラメータが含まれ、応答メッセージにはプロシージャの結果が含まれます。応答メッセージが受信されると、プロシージャの結果が抽出され、呼び出し元の実行が再開されます。
NETCONF プロトコルは、リモート プロシージャ コール (RPC) パラダイムを使用します。クライアントは RPC を XML [W3C.REC-xml-20001006] でエンコードし、安全な接続指向のセッションを使用してサーバーに送信します。サーバーは、XML でエンコードされた応答で応答します。要求と応答の両方のコンテンツは、XML DTD または XML スキーマ、あるいはその両方で完全に記述されているため、両当事者は交換に課せられた構文の制約を認識することができます。
NETCONF は、RPC ベースの通信パラダイムを使用します。クライアントは一連の 1 つ以上の RPC 要求メッセージを送信します。これにより、サーバーは対応する一連の RPC 応答メッセージで応答します。
RPC に関するウィキペディアのページも同様です。
RPC は一種の要求応答プロトコルです。RPC はクライアントによって開始され、指定されたパラメーターを使用して指定されたプロシージャを実行するために、要求メッセージを既知のリモート サーバーに送信します。リモート サーバーはクライアントに応答を送信し、アプリケーションはそのプロセスを続行します。サーバーが呼び出しを処理している間、クライアントはブロックされます (実行を再開する前に、サーバーが処理を終了するまで待機します)。ただし、クライアントが XHTTP 呼び出しなどの非同期要求をサーバーに送信する場合を除きます。さまざまな実装には多くのバリエーションと微妙な点があり、その結果、さまざまな (互換性のない) RPC プロトコルが生まれます。
（遅くなるよりは遅くなる方がいいですよね？）