On Tue, Jan 12 2021, Jeff Hostetler via GitGitGadget wrote: > From: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx> > > Brief design documentation for new IPC mechanism allowing > foreground Git client to talk with an existing daemon process > at a known location using a named pipe or unix domain socket. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > Signed-off-by: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx> > --- > Documentation/technical/api-simple-ipc.txt | 31 ++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > create mode 100644 Documentation/technical/api-simple-ipc.txt > > diff --git a/Documentation/technical/api-simple-ipc.txt b/Documentation/technical/api-simple-ipc.txt > new file mode 100644 > index 00000000000..920994a69d3 > --- /dev/null > +++ b/Documentation/technical/api-simple-ipc.txt > @@ -0,0 +1,31 @@ > +simple-ipc API > +============== > + > +The simple-ipc API is used to send an IPC message and response between > +a (presumably) foreground Git client process to a background server or > +daemon process. The server process must already be running. Multiple > +client processes can simultaneously communicate with the server > +process. > + > +Communication occurs over a named pipe on Windows and a Unix domain > +socket on other platforms. Clients and the server rendezvous at a > +previously agreed-to application-specific pathname (which is outside > +the scope of this design). > + > +This IPC mechanism differs from the existing `sub-process.c` model > +(Documentation/technical/long-running-process-protocol.txt) and used > +by applications like Git-LFS because the server is assumed to be very s/to be very long running/to be a long running/, or at least "s/to be very/to be a very/. > +long running system service. In contrast, a "sub-process model process" > +is started with the foreground process and exits when the foreground > +process terminates. How the server is started is also outside the > +scope of the IPC mechanism. > + > +The IPC protocol consists of a single request message from the client and > +an optional request message from the server. For simplicity, pkt-line > +routines are used to hide chunking and buffering concerns. Each side > +terminates their message with a flush packet. > +(Documentation/technical/protocol-common.txt) > + > +The actual format of the client and server messages is application > +specific. The IPC layer transmits and receives an opaque buffer without > +any concern for the content within.
