Restricciones de campos y rangos de valores ​

Campos de solicitud (C→S) ​

• No hay wait ni lease infinitos. Los clientes oficiales redondean hacia arriba las fracciones de segundo, validan el rango y devuelven un error de entrada explícito antes de enviar, sin clamp. El lease predeterminado es de 30 segundos.
• En la API oficial, wait es el límite total del acquire desde el inicio de la llamada, pasando por local queue, reintentos de conexión definitivamente no enviados y write, hasta la respuesta. Se crea una sola monotonic operation deadline; justo antes del envío real, el writer coloca en el wait del frame el techo u8 de los segundos restantes. Por tanto, una conexión tardía o un failover definitivamente no enviado no puede reiniciar el server wait. Si al llegar la deadline la solicitud sigue en queue, vence como timeout definitivamente no enviado; si pudo enviarse siquiera un byte, se cierra esa session exacta y el resultado es Indeterminate. Solo un wait=0 original usa wire 0, y ese intento inmediato tiene otra I/O deadline finita para no esperar indefinidamente un transport bloqueado. Si un A ya correlacionado justo antes de la deadline se descubre tarde en el gate de entrega del Ticket, el server waiter ya terminó: se mantiene abierta la session, se libera en compensación el exact token conocido y se devuelve Indeterminate. Los T/B correlacionados siguen siendo no adquisiciones definitivas.
• Para un wait=0 original, el comportamiento wire y server sigue siendo un único intento inmediato sin queue. Dentro de su transport deadline separada de cinco segundos, un fallo definitivamente no enviado puede elegir otra conexión y reintentar con el mismo owner. Una vez que pudo enviarse siquiera un byte, el acquire nunca se reenvía.
• La API oficial exige min_work_budget, que no viaja por wire. Cubre trabajo crítico + pausa prevista + finalización de commit/rollback DB, está en 0..250 segundos y no supera el lease normalizado. Si no, falla antes del envío con un error tipo UnsupportedDuration/InsufficientLease.
• La longitud de la clave se mide en bytes, no en caracteres — los caracteres acentuados ocupan 2 bytes en UTF-8, así que una clave solo de acentuados llega a 64 caracteres.
• owner solo es un ID de correlación de respuesta, no autoridad. Reutilizarlo no devuelve un active token ni renueva el lease. Las solicitudes in-flight simultáneas de un cliente deben usar valores no nulos distintos; si el contador llega a 0 o hace wrap, los clientes oficiales fallan de forma cerrada.
• Los releases explícitos y compensatorios de un token conocido tienen 5 segundos absolutos desde call/enqueue, incluidas reconexiones y reintentos. R confirma éxito; N indica que ya no existe o no es el token actual. Sin respuesta nunca se supone éxito; una cola compensatoria limitada llena recurre a la expiración del lease.
• bad_key cubre por igual una clave vacía, una que supere 128 bytes, una que contenga espacio o salto de línea, y UTF-8 inválido. Los clientes oficiales, además, nunca envían \r — una clave terminada en \r se convertiría silenciosamente en una clave distinta.

Campos de respuesta (S→C) ​

El servidor nunca emite el token 0. Single usa un contador durante la vida del proceso; cluster usa un contador replicado por consenso y falla de forma cerrada antes del overflow. Ni wall clock ni aleatoriedad garantizan monotonía tras reiniciar.

Longitudes de cabecera fija ​

El tramo binario de longitud fija que sigue al op. Estos bytes pueden contener 0x0A, así que el analizador debe consumir exactamente esa cantidad antes de buscar el salto de línea.

Si faltan bytes, se devuelve E bad_request.

Tamaño de trama ​

El límite de 192B supera la trama máxima (146B), por lo que un cliente conforme no lo alcanza. Tras una trama estructuralmente inválida u oversized, deja de confiarse en el framing y se cierra la conexión.

Handshake de autenticación ​

Consulta Handshake de autenticación para el procedimiento completo.

Límites del servidor ​

El cliente no fija directamente estos valores, pero afectan a su comportamiento.

El read buffer (4096B), batch de respuestas (64), progress timeout de una trama client iniciada (5 s) y sweep de expiración single (5 s) son constantes de compilación. Cluster expiry usa un deadline min-heap que valida tokens, no un escaneo completo. Véase Configuración.

La admisión de acquires, keys nuevas y waiters globales se cierra al 90 % del hard limit y solo reabre por debajo del 75 %. Por eso un acquire nuevo puede recibir B antes del límite; la capacidad reservada para release y recuperación Raft queda separada de esta histéresis.

Resumen: incumplimiento → respuesta ​

Para todos los motivos de error y el tratamiento de la conexión, consulta Respuesta · Error E.