sozu/command
Eloi DEMOLIS c5ff06a12b release: v1.0.6
Signed-off-by: Eloi DEMOLIS <eloi.demolis@clever-cloud.com>
2024-12-05 10:44:32 +01:00
..
assets add example 404 and 508 errors 2024-04-05 10:31:29 +02:00
examples command::logging::logs apply review 2024-07-17 16:20:52 +02:00
src apply clippy suggestions 2024-11-07 15:51:26 +01:00
Cargo.toml release: v1.0.6 2024-12-05 10:44:32 +01:00
README.md document protobuf in the sozu-command-lib README 2023-05-03 15:05:33 +02:00
build.rs apply clippy fixes 2023-05-05 17:32:09 +02:00
state.json translate WorkerRequest and WorkerResponse to protobuf 2024-02-02 16:37:58 +01:00

README.md

sozu-command-lib, tools to communicate with the Sōzu proxy

The sozu proxy can receive dynamic configuration changes through a unix socket. This library defines the communication protocol, the message format, the required structures, serialization and deserialization code.

Command messages are defined in protobuf

Protobuf is a language-agnostic, binary serialization format used to efficiently transmit structured data between different systems and languages.

The idea is to define the data once in this format, so that various libraries of various languages can translate it to their own.

All types are defined in the command.proto file. There are two main types received by, and sent from, Sōzu:

  • Request
  • Response

They look like this, in protobuf:

// A message received by Sōzu to change its state or query information
message Request {
  oneof request_type {
    // save Sōzu's parseable state as a file, with a path
    string save_state = 1;
    // load a state file, given its path
    string load_state = 2;
    /*
    40 more requests
    */
  }
}
// Response to a request
message Response {
    // wether the request was a success, a failure, or is processing
    required ResponseStatus status = 1 [default = FAILURE];
    // a success or error message
    required string message = 2;
    // response data, if any
    optional ResponseContent content = 3;
}

These are serialized in binary, NOT in plain text formats like JSON.

A response can have 3 possible status:

  • Ok: the task was done
  • Failure: there was an unrecoverable error
  • Processing: the task was started but may not finish right away

As an example, in a soft shutdown, the shutdown message is sent to all the workers, and they acknowledge the message by sending an answer with the Processing status: in a soft shutdown, a worker stops accepting new connections but keeps the active ones and exits when they are no longer active. Once all connections are done, a worker will send an answer with the same id and the Ok status.