简体中文 ▾ 主题 ▾ 最新版本 ▾ api-simple-ipc 最后更新于 2.49.0

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 风格的子进程模型中，辅助程序由前台进程启动，通信通过绑定到子进程 stdin/stdout 的一对文件描述符进行，子进程只服务于当前的前台进程，并且在前台进程终止时子进程也退出。

在 Simple-IPC 模型中，服务端是一个非常长久运行的服务。它可以同时服务多个客户端，并拥有到每个活跃客户端的私有套接字或命名管道连接。它可能由当前的客户端进程按需启动，也可能由之前的客户端或在操作系统启动时启动。服务端进程不与终端关联，并且在客户端终止后仍然存在。客户端无法访问服务端进程的 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