English ▾ Themen ▾ Neueste Version ▾ api-simple-ipc zuletzt aktualisiert in 2.49.0

Die Simple-IPC-API ist eine Sammlung von Bibliotheksroutinen mit dem Präfix ipc_ und ein grundlegendes Kommunikationsprotokoll, das es einem IPC-Client-Prozess ermöglicht, eine anwendungsspezifische IPC-Anforderungsnachricht an einen IPC-Server-Prozess zu senden und eine anwendungsspezifische IPC-Antwortnachricht zu empfangen.

Die Kommunikation erfolgt über eine benannte Pipe unter Windows und einen Unix-Domain-Socket auf anderen Plattformen. IPC-Clients und IPC-Server treffen sich an einem zuvor vereinbarten anwendungsspezifischen Pfadnamen (der außerhalb des Rahmens dieses Designs liegt), der lokal für das Computersystem ist.

Die IPC-Server-Routinen innerhalb des Serveranwendungsprozesses erstellen einen Thread-Pool, um auf Verbindungen zu lauschen und Anforderungsnachrichten von mehreren gleichzeitigen IPC-Clients zu empfangen. Nach dem Empfang werden diese Nachrichten an die Serveranwendungs-Callbacks zur Verarbeitung weitergeleitet. IPC-Server-Routinen leiten dann schrittweise Antworten an den IPC-Client weiter.

Die IPC-Client-Routinen innerhalb eines Clientanwendungsprozesses stellen eine Verbindung zum IPC-Server her, senden eine Anforderungsnachricht und warten auf eine Antwort. Nach dem Empfang wird die Antwort an den Aufrufer zurückgegeben.

Zum Beispiel wird die Funktion fsmonitor--daemon als Serveranwendung auf Basis der IPC-Server-Bibliotheksroutinen aufgebaut. Sie wird Threads haben, die auf Dateisystemereignisse warten, und einen Thread-Pool, der auf Clientverbindungen wartet. Clients, wie z. B. git status, werden eine Liste von Dateisystemereignissen seit einem bestimmten Zeitpunkt anfordern, und der Server wird mit einer Liste geänderter Dateien und Verzeichnisse antworten. Die Formate von Anforderung und Antwort sind anwendungsspezifisch; die IPC-Client- und IPC-Server-Routinen behandeln sie als undurchsichtige Byte-Streams.

Vergleich mit dem Subprozessmodell

Der Simple-IPC-Mechanismus unterscheidet sich vom bestehenden Modell sub-process.c (Dokumentation/technical/long-running-process-protocol.adoc), das von Anwendungen wie Git-LFS verwendet wird. Im LFS-ähnlichen Subprozessmodell wird der Helfer vom Vordergrundprozess gestartet, die Kommunikation erfolgt über ein Paar von Dateideskriptoren, die an stdin/stdout des Subprozesses gebunden sind, der Subprozess bedient nur den aktuellen Vordergrundprozess, und der Subprozess wird beendet, wenn der Vordergrundprozess terminiert.

Im Simple-IPC-Modell ist der Server ein sehr langlebiger Dienst. Er kann viele Clients gleichzeitig bedienen und hat eine private Socket- oder benannte Pipe-Verbindung zu jedem aktiven Client. Er kann (bei Bedarf) vom aktuellen Clientprozess gestartet werden, oder er wurde von einem früheren Client oder vom Betriebssystem beim Systemstart gestartet. Der Serverprozess ist nicht mit einem Terminal verbunden und bleibt bestehen, nachdem Clients beendet wurden. Clients haben keinen Zugriff auf stdin/stdout des Serverprozesses und müssen daher über Sockets oder benannte Pipes kommunizieren.

Serverstart und -abschaltung

Wie ein Anwendungsserver auf Basis von IPC-Server gestartet wird, liegt ebenfalls außerhalb des Rahmens des Simple-IPC-Designs und ist eine Eigenschaft der Anwendung, die ihn verwendet. So kann der Server beispielsweise während routinemäßiger Wartungsarbeiten gestartet oder neu gestartet werden, oder er kann als Systemdienst während des Systemstartvorgangs gestartet werden, oder er kann bei Bedarf von einem Git-Befehl im Vordergrund gestartet werden.

Ebenso ist die Serverabschaltung eine Eigenschaft der Anwendung, die die Simple-IPC-Routinen verwendet. Der Server kann beispielsweise entscheiden, sich im Leerlauf abzuschalten oder nur auf ausdrückliche Anforderung.

Simple-IPC-Protokoll

Das Simple-IPC-Protokoll besteht aus einer einzigen Anforderungsnachricht vom Client und einer optionalen Antwortnachricht vom Server. Sowohl die Client- als auch die Servernachrichten sind unbegrenzt lang und werden mit einem Flush-Paket beendet.

Die pkt-line Routinen (gitprotocol-common[5]) werden verwendet, um die Pufferverwaltung während der Nachrichten-Erzeugung, -Übertragung und -Empfang zu vereinfachen. Ein Flush-Paket wird verwendet, um das Ende der Nachricht zu markieren. Dies ermöglicht es dem Sender, die Nachricht inkrementell zu generieren und zu übertragen. Es ermöglicht dem Empfänger, die Nachricht inkrementell in Chunks zu empfangen und zu wissen, wann er die gesamte Nachricht erhalten hat.

Das tatsächliche Byte-Format der Client-Anforderungs- und Server-Antwortnachrichten ist anwendungsspezifisch. Die IPC-Schicht überträgt und empfängt sie als undurchsichtige Byte-Puffer, ohne sich um den Inhalt zu kümmern. Es ist die Aufgabe der aufrufenden Anwendungsschicht, den Inhalt der Anfrage- und Antwortnachrichten zu verstehen.

Zusammenfassung

Konzeptionell ähnelt das Simple-IPC-Protokoll einer HTTP-REST-Anfrage. Clients verbinden sich, stellen eine anwendungsspezifische und zustandslose Anfrage, erhalten eine anwendungsspezifische Antwort und trennen die Verbindung. Es handelt sich um eine Einmal-Round-Trip-Einrichtung zur Abfrage des Servers. Die Simple-IPC-Routinen verbergen die Details von Sockets, benannten Pipes und Thread-Pools und ermöglichen es der Anwendungsschicht, sich auf die anstehende Aufgabe zu konzentrieren.