"Jeff Hostetler via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > +How the simple-ipc server is started is also outside the scope of the > +IPC mechanism. For example, the server might be started during > +maintenance operations. Just a tiny nit. I would expect to see "might be <re>started" if it is followed by "during maintenance operations"; in other words, I expect "might be started" to be followed by "as part of the boot-up sequence". > +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) Hidign chunking and buffering concerns is good, but it introduces some limitations, like 64k chunk limit, which probably want to be mentioned (if not explained or described) here. Do we give any extra meaning over "here, a message ends" to the flush packet? The lack of "now it is your turn to speak" (aka "delim") has long been a weakness of the over-the-wire protocol, and we'd probably want to learn from the past experience. > +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. Please sell why such a semantic-agnostic layer exists and what benefit the callers would get out of it. Perhaps you offer some mechanism to allow them to send and receive without having to worry about deadlocks[*]? THanks. [Footnote] *1* ...just an example benefit that may or may not exist.
