Simple-IPC API 是一组带有 ipc_ 前缀的库例程和一个基本的通信协议，它允许 IPC 客户端进程向 IPC 服务器进程发送特定于应用程序的 IPC 请求消息，并接收特定于应用程序的 IPC 响应消息。

通信发生在 Windows 上的命名管道和其它平台上的 Unix 域套接字上。 IPC 客户端和 IPC 服务器在先前约定好的、特定于应用程序的路径名（不在本设计的范围之内）处会合，该路径名位于计算机系统的本地。

服务器应用程序进程内的 IPC 服务器例程创建一个线程池来监听连接并接收来自多个并发 IPC 客户端的请求消息。收到消息后，这些消息被分派到服务器应用程序回调函数进行处理。然后，IPC 服务器例程逐步将响应中继回 IPC 客户端。

客户端应用程序进程内的 IPC 客户端例程连接到 IPC 服务器，发送请求消息并等待响应。收到响应后，响应将返回给调用者。

例如，fsmonitor--daemon 功能将作为基于 IPC 服务器库例程的服务器应用程序构建。它将具有用于监视文件系统事件的线程，以及一个等待客户端连接的线程池。客户端（例如 git status）将请求自某个时间点以来的文件系统事件列表，服务器将响应一个已更改文件和目录的列表。请求和响应的格式是特定于应用程序的； IPC 客户端和 IPC 服务器例程将它们视为不透明的字节流。

与子进程模型比较

Simple-IPC 机制与现有的 sub-process.c 模型 (Documentation/technical/long-running-process-protocol.adoc) 不同，该模型被 Git-LFS 等应用程序使用。在 LFS 样式的子进程模型中，helper 由前台进程启动，通信通过绑定到子进程 stdin/stdout 的一对文件描述符进行，子进程仅服务于当前前台进程，并且子进程在前台进程终止时退出。

在 Simple-IPC 模型中，服务器是一个长时间运行的服务。 它可以同时为多个客户端提供服务，并且具有到每个活动客户端的专用套接字或命名管道连接。 它可能由当前客户端进程（按需）启动，或者可能已由先前的客户端或 OS 在启动时启动。 服务器进程不与终端相关联，并且在客户端终止后仍然存在。 客户端无权访问服务器进程的 stdin/stdout，因此必须通过套接字或命名管道进行通信。

服务器启动和关闭

基于 IPC 服务器的应用程序服务器如何启动也超出了 Simple-IPC 设计的范围，并且是使用它的应用程序的属性。 例如，服务器可能会在例行维护操作期间启动或重新启动，或者可能作为系统服务在系统启动序列期间启动，或者可能在需要时由前台 Git 命令按需启动。

类似地，服务器关闭是使用 simple-ipc 例程的应用程序的属性。 例如，服务器可能会决定在空闲时或仅在显式请求时关闭。

Simple-IPC 协议

Simple-IPC 协议由来自客户端的单个请求消息和来自服务器的可选响应消息组成。 客户端和服务器消息的长度都是无限的，并以刷新包终止。

pkt-line 例程 (gitprotocol-common[5]) 用于简化消息生成、传输和接收期间的缓冲区管理。 刷新包用于标记消息的结尾。 这允许发送者增量地生成和传输消息。 它允许接收者以块的形式增量地接收消息，并知道他们何时已接收到整个消息。

客户端请求和服务器响应消息的实际字节格式是特定于应用程序的。 IPC 层传输和接收它们作为不透明的字节缓冲区，而不关心其中的内容。 了解请求和响应消息的内容是调用应用程序层的工作。

总结

从概念上讲，Simple-IPC 协议类似于 HTTP REST 请求。 客户端连接，发出特定于应用程序的无状态请求，接收特定于应用程序的响应，然后断开连接。 这是一个用于查询服务器的单程机制。 Simple-IPC 例程隐藏了套接字、命名管道和线程池的细节，并允许应用程序层专注于手头的任务。

scroll-to-top