Biblioteca Ticketing para C/C++ ​

Aún no está registrado en el registro oficial de vcpkg — los requisitos de aceptación son estrictos y el registro sigue en curso. Por ahora, clone el repositorio de Github anterior y compílelo usted mismo.

Repositorio ​

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.

#include <ticketing/ticketing.h>

const char *addrs[] = {"127.0.0.1:5225"};
ticketing_broker *broker = ticketing_connect(addrs, 1);
ticketing_wait_ready(broker, 5);

ticketing_ticket *ticket = NULL;
if (ticketing_acquire(broker, "key", 5.0, 30.0, 2.0, &ticket) == TICKETING_OK) {
    uint64_t token = ticketing_ticket_token(ticket);
    /* In the same DB transaction: verify/update token high-water and perform the business write. */
    ticketing_release(ticket, NULL);
}

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).

const char *addrs[] = {"10.0.0.1:5225", "10.0.0.2:5225", "10.0.0.3:5225"};
ticketing_options options = {
    .token = "123",
    .tls = "system-roots", /* NULL(off) | "insecure-skip-verify" | ruta a un archivo CA */
};
ticketing_result error;
ticketing_broker *broker = ticketing_connect_with(addrs, 3, &options, &error);

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.