github.com/nycdavid/zeus@v0.0.0-20201208104106-9ba439429e03/docs/master_slave_handshake.md (about)

     1  # Master/Slave Handshake
     2  
     3  #### 1. Socket
     4  
     5  The Slave is always started with an environment variable named `ZEUS_MASTER_FD`. The file descriptor at the given integer value is a socket to the Master process.
     6  
     7  The Slave should open a UNIX Domain Socket using the `ZEUS_MASTER_FD` File Descriptor (`globalMasterSock`).
     8  
     9  The Slave opens a new UNIX datagram Socketpair (`local`, `remote`)
    10  
    11  The Slave sends `remote` across `globalMasterSock`.
    12  
    13  #### 2. PID and Identifier
    14  
    15  The Slave determines whether it has been given an Identifier. If it is the first-booted slave, it was booted
    16  by the Master, and will not have one. When a Slave forks, it is passed an Identifier by the Master that it
    17  passes along to the newly-forked process.
    18  
    19  The Slave sends a "Pid & Identifier" message containing the pid and the identifier (blank if initial process)
    20  
    21  #### 4. Action Result
    22  
    23  The Slave now executes the code it's intended to run by looking up the action
    24  in a collection of predefined actions indexed by identifier. In ruby this is implemented
    25  as a module that responds to a method named according to each identifier.
    26  
    27  If there were no runtime errors in evaluating the action, the Slave writes "OK" to `local`.
    28  
    29  If there were runtime errors, the slave returns a string representing the errors in an arbitrary and
    30  hopefully helpful format. It should normally be identical to the console output format should the errors
    31  have been raised and printed to stderr.
    32  
    33  Before the server kills a crashed slave process, it attempts to read
    34  any loaded files from `local`, until that socket is closed.
    35  
    36  #### 5. Loaded Files
    37  
    38  Any time after the action has been executed, the Slave may (and should) send, over `local`, a list of files
    39  that have been newly-loaded in the course of evaluating the action.
    40  
    41  Languages are expected to implement this using clever tricks.
    42  
    43  Steps 1-4 happend sequentially and in-order, but Submitting files in Step 5 should not prevent the Slave from
    44  handling further commands from the master. The Slave should be considered 'connected' after Step 4.