Actualmente en pruebas: el código de GitHub se abrirá al finalizar.

Sesión de ejemplo (notación de bytes)

Los enteros son big-endian. ·· es solo una marca de límite de byte, no un byte real. owner y token son u64, es decir 8 bytes cada uno, pero abajo se abrevian como ⟨owner=7⟩ / ⟨token=1⟩ para facilitar la lectura.

# Authentication (once per connection)
server → "SHA-256 aB3dEf_g" \n
client → base64url( SHA-256( token ∥ "aB3dEf_g" ) ) \n

# Immediate acquire: wait=5s, lease=30s, key="order-1234"
client → 'A' 05 1E ⟨owner=7⟩ "order-1234" \n
server → 'A' ⟨token=1⟩ ⟨owner=7⟩ "order-1234" \n

# A different connection waits for the held key: wait=1s
client2 → 'A' 01 1E ⟨owner=9⟩ "order-1234" \n
                                      ... pending ...
# Release hands the key directly to the FIFO head with a new token
client  → 'R' ⟨token=1⟩ "order-1234" \n
server  → 'R' ⟨token=1⟩ "order-1234" \n
server  → 'A' ⟨token=2⟩ ⟨owner=9⟩ "order-1234" \n
# Or, when wait expires without a grant
server  → 'T' ⟨owner=9⟩ "order-1234" \n

# Response lost after an acquire may have been sent
client → 'A' 05 1E ⟨owner=10⟩ "payment-42" \n
connection closed                         # Indeterminate; do not resend A with owner=10

# Capacity rejection proves non-acquisition; no internal retry
client3 → 'A' 05 1E ⟨owner=11⟩ "order-1234" \n
server  → 'B' ⟨owner=11⟩ "order-1234" \n

# Exact-token release mismatch and malformed request
client → 'R' ⟨token=1⟩ "order-1234" \n
server → 'N' ⟨token=1⟩ "order-1234" \n
client → 'Z' ...
server → 'E' "bad_op" \n
connection closed

# Request sent to a non-leader
client → 'A' 05 1E ⟨owner=13⟩ "order-1234" \n
server → 'M' "10.0.0.1:5225" \n
connection closed                         # sent acquire is Indeterminate; M has no owner

# Server-initiated leader notice; this connection stays open
server → 'L' "10.0.0.2:5225" \n

La razón de repetir owner y token se explica en las reglas de emparejamiento. Las respuestas pueden llegar fuera del orden de requests, así que se asocian por identifier repetido, no FIFO.

El consenso cluster entre servidores se describe en Protocol (Cluster).