| Message ID | 7064c5e9ffa0e3e666ea6d146b0839680952757d.1610465493.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Simple IPC Mechanism | expand |
On Tue, Jan 12 2021, Jeff Hostetler via GitGitGadget wrote: > From: Jeff Hostetler <jeffhost@microsoft.com> > > 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@gmx.de> > Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> > --- > 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.
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 +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.