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

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

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

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

例えば、 fsmonitor--daemon 機能は IPC-server ライブラリ・ルーチンを土台としてサーバー・アプリケーションとして構築されます。 このデーモンは、 ファイルシステム・イベントを監視するスレッド群と、 クライアントからの接続を待つスレッド・プールを持つことになります。 git status のようなクライアントは、 ある時点以降のファイルシステム・イベントのリストをリクエストし、 サーバーは変更されたファイルとディレクトリーのリストで応答します。 リクエストと応答のフォーマットはアプリケーション固有であり、 IPC-client と IPC-server のルーチンはそれらを不透明なバイト・ストリームとして扱います。

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

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 ルーチンは、 ソケットや、 名前付きパイプや、 スレッドプールの詳細を隠し、 アプリケーション層が手元のタスクに集中できるようにします。