Simple-IPC APIは、 ipc_ プレフィックス付きライブラリルーチンと基本的な通信プロトコルのコレクションであり、IPCクライアントプロセスがアプリケーション固有のIPC要求メッセージをIPCサーバープロセスに送信し、アプリケーション固有のIPC応答メッセージを受信できるようにします。

通信は、Windowsでは名前付きパイプを介して、他のプラットフォームではUnixドメインソケットを介して行われます。 IPCクライアントとIPCサーバーは、コンピューターシステムに対してローカルである、以前に合意されたアプリケーション固有のパス名(この設計の範囲外)で会合(rendezvous)します。

サーバーアプリケーションプロセス内のIPCサーバールーチンは、接続をリッスンし、複数の同時IPCクライアントから要求メッセージを受信するためのスレッドプールを作成します。 受信すると、これらのメッセージは処理のためにサーバーアプリケーションのコールバックまでディスパッチされます。 次に、IPCサーバールーチンは、応答をIPCクライアントに段階的にリレー(incrementally relay)します。

クライアントアプリケーションプロセス内のIPCクライアントルーチンはIPCサーバーに接続し、要求メッセージを送信して応答を待ちます。 受信すると、応答は呼び出し元に返されます。

たとえば、 fsmonitor--daemon 機能は、IPCサーバーライブラリルーチンの上にサーバーアプリケーションとして構築されます。 ファイルシステムイベントを監視するスレッドと、クライアント接続を待機するスレッドプールがあります。 git status などのクライアントは、ある時点以降のファイルシステムイベントのリストを要求し、サーバーは変更されたファイルとディレクトリのリストで応答します。 要求と応答の形式はアプリケーション固有です。 IPCクライアントおよびIPCサーバールーチンは、それらを不透明なバイトストリームとして扱います。

サブプロセスモデルとの比較

Simple-IPCメカニズムは、既存の sub-process.c モデル(Documentation/technical/long-running-process-protocol.txt)とは異なり、Git-LFSなどのアプリケーションで使用されます。 LFSスタイルのサブプロセスモデルでは、ヘルパーはフォアグラウンドプロセスによって開始され、通信はサブプロセスの stdin/stdout にバインドされたファイル・デスクリプタのペアを介して行われ、サブプロセスは現在のフォアグラウンドプロセスのみを提供します。 フォアグラウンドプロセスが終了すると、サブプロセスは終了します。

Simple-IPCモデルでは、サーバーは非常に長時間実行されるサービスです。 同時に多くのクライアントにサービスを提供でき、アクティブな各クライアントへのプライベートソケットまたは名前付きパイプ接続があります。 現在のクライアントプロセスによって(オンデマンドで)開始されたか、以前のクライアントまたは起動時にOSによって開始された可能性があります。 サーバープロセスは端末に関連付けられておらず、クライアントが終了した後も存続します。 クライアントはサーバープロセスの stdin/stdout にアクセスできないため、ソケットまたは名前付きパイプを介して通信する必要があります。

Server startup and shutdown

IPCサーバーに基づくアプリケーションサーバーの起動方法も Simple-IPC 設計の範囲外であり、それを使用するアプリケーションの範疇です。 たとえば、サーバーは定期的なメンテナンス操作中に起動または再起動されたり、システムの起動シーケンス中にシステムサービスとして起動されたり、必要に応じてフォアグラウンドGitコマンドによってオンデマンドで起動されたりする場合があります。

同様に、サーバーのシャットダウンは、simple-ipc ルーチンを使用するアプリケーションの範疇です。 たとえば、サーバーは、アイドル状態のとき、または明示的な要求があった場合にのみシャットダウンすることを決定する場合があります。

Simple-IPC protocol

Simple-IPCプロトコルは、クライアントからの単一の要求メッセージとサーバーからのオプションの応答メッセージで構成されます。 クライアントメッセージとサーバーメッセージはどちらも長さが無制限で、フラッシュパケットで終了します。

pkt-lineルーチン達(gitprotocol-common(5))は、メッセージの、生成中や送信中や受信中の、バッファー管理を簡素化するために使用されます。 フラッシュパケットは、メッセージの終わりを示すために使用されます。 これにより、送信側はメッセージを段階的に生成して送信できます。 これにより、受信者はメッセージをチャンクで段階的に受信し、メッセージ全体をいつ受信したかを知ることができます。

クライアント要求およびサーバー応答メッセージの実際のバイト形式は、アプリケーション固有です。 IPC層は、内部のコンテンツを気にすることなく、不透明なバイトバッファとしてそれらを送受信します。 要求メッセージと応答メッセージの内容を理解するのは、呼び出し元のアプリケーション層の仕事です。

Summary

概念的には、Simple-IPCプロトコルは HTTP REST 要求に似ています。 クライアントは接続し、アプリケーション固有のステートレス要求を作成し、アプリケーション固有の応答を受信して、切断します。 これは、サーバーでクエリを実行するための1回の往復機能です。 Simple-IPCルーチンは、ソケットや、名前付きパイプや、スレッドプールの詳細を非表示にし、アプリケーション層が手元のアプリケーションに集中できるようにします。