github.com/nycdavid/zeus@v0.0.0-20201208104106-9ba439429e03/docs/client_master_handshake.md (about) 1 # Client/Master/Command handshake 2 3 Client Master Command 4 1 ----------> | Command, Arguments, Pid 5 2 ----------> | Terminal IO 6 3 -----------> | Terminal IO 7 4 -----------> | Arguments, Pid 8 5 <----------- | pid 9 6 <--------- | pid 10 (time passes) 11 7 <----------- | exit status 12 8 <--------- | exit status 13 14 15 #### 1. Command & Arguments (Client -> Master) 16 17 The Master always has a UNIX domain server listening at a known socket path. 18 19 The Client connects to this server and sends a string indicating the command to run and any arguments to run with (ie. the ARGV). See message_format.md for more info. 20 21 #### 2. Terminal IO (Client -> Master) 22 23 The Client then sends an IO over the server socket to be used for raw terminal IO. 24 25 #### 3. Arguments (Master -> Command) 26 27 The Master sends the Client arguments from step 1 to the Command. 28 29 #### 4. Terminal IO (Master -> Command) 30 31 The Master forks a new Command process and sends it the Terminal IO from the Client. 32 33 #### 5. Pid (Command -> Master) 34 35 The Command process sends the Master its pid, using a Pid & Identifier message. 36 37 #### 6. Pid (Master -> Client) 38 39 The Master responds to the client with the pid of the newly-forked Command process. 40 41 The Client is now connected to the Command process. 42 43 #### 7. Exit status (Command -> Master) 44 45 When the command terminates, it must send its exit code to the master. This is normally easiest to implement as a wrapper process that does the setsid, then forks the command and `waitpid`s on it. 46 47 The form of this message is `{{code}}`, eg: `1`. 48 49 #### 8. Exit status (Master -> Client) 50 51 Finally, the Master forwards the exit status to the Client. The command cycle is now complete. 52 53 The form of this message is `{{code}}`, eg: `1`. 54 55 See [`message_format.md`](message_format.md) for more information on messages. 56