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

Biblioteca Ticketing para Rust

GitHub crates.io

Repositorio

toml

Ejemplo

Ejemplo básico

Cree un broker al iniciar la aplicación y compártalo. wait=0 es un intento inmediato sin cola, máximo 255 s; lease es 1–250 s. El minimum-work budget final es obligatorio y puede ser cero. Las fracciones de segundo se redondean hacia arriba y los valores fuera de rango o un budget mayor que el lease normalizado se rechazan antes de enviar, nunca se clampan.

rust
use std::time::Duration;
use ticketing::TicketBroker;

let broker = TicketBroker::connect(["127.0.0.1:5225"]);
broker.wait_ready(Duration::from_secs(5)).await;

let ticket = broker.acquire(
    "key",
    Duration::from_secs(5),
    Duration::from_secs(30),
    Duration::from_secs(2),
).await?;
let token = ticket.token();
// In the same DB transaction: verify/update token high-water and perform the business write.
ticket.release().await?;

El close/drop automático es un release bounded best-effort. Use la API de release explícito si importa el resultado. El token debe aplicar fencing al write DB protegido dentro de la misma transaction.

Conviene saber (comportamiento)

  • Si pudo enviarse un byte, perder la respuesta definitiva produce Indeterminate. No se reenvía A automáticamente con el mismo owner; el caller no entra en la sección crítica.
  • Cancel antes de send es unsent; tras possible-send cierra la sesión. Si se parseó a la vez un grant token, intenta un release compensatorio exact-token limitado.
  • M, todos los E y respuestas malformed/oversized/unknown son session-fatal. Acquires possible-send no resueltos quedan Indeterminate.
  • B es rechazo definitivo de capacity y vuelve inmediatamente. Sin retry interno; el caller puede iniciar acquire nuevo con owner nuevo y backoff de aplicación.
  • Releases explícitos/compensatorios reintentan exact token solo durante 5 segundos absolutos desde call/enqueue. R éxito, N ausente/no actual; sin respuesta final es error, nunca éxito supuesto.
  • Solo se entrega Ticket con tiempo conservador positivo suficiente para work budget. Trabajo superior a 250 s es unsupported antes de enviar.
  • El fencing DB con token es obligatorio: en la misma transaction rechace token <= stored_high_water, actualice high-water y haga business write antes de commit/rollback y release.

Opciones de seguridad (Token · TLS)

Todas las opciones son opcionales. token debe coincidir con client_tokens del servidor, y TLS tiene cuatro modos: desactivado / almacén de confianza del sistema / una CA indicada / omitir verificación (solo para pruebas).

rust
use ticketing::{TicketBroker, TlsMode};

let broker = TicketBroker::builder()
    .addrs(["10.0.0.1:5225", "10.0.0.2:5225", "10.0.0.3:5225"])
    .token("123")
    .tls(TlsMode::SystemRoots)
    // .tls(TlsMode::Ca("ca.crt".into()))
    // .tls(TlsMode::InsecureSkipVerify)
    .connect()?;

Puedes generar la configuración del token, TLS y el clúster en el lado del servidor en la página Despliegue del servidor Ticketing.