Bibliothèque Ticketing C/C++ ​

Pas encore enregistré dans le registre officiel vcpkg — les critères de soumission sont stricts et l'enregistrement est toujours en cours. En attendant, clonez le dépôt Github ci-dessus et compilez-le vous-même.

Dépôt ​

Exemple ​

Exemple simple ​

Créez un broker au démarrage et partagez-le. wait=0 est une tentative immédiate sans file, au maximum 255 s ; lease vaut 1–250 s. Le minimum-work budget final est obligatoire et peut valoir zéro. Les fractions de seconde sont arrondies vers le haut et les valeurs hors plage ou un budget supérieur au bail normalisé sont rejetés avant envoi, jamais clampés.

#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);
}

Le close/drop automatique est un release borné best-effort. Utilisez l'API de release explicite si le résultat compte. Le token doit protéger l'écriture DB dans la même transaction.

Bon à savoir (comportement) ​

• Dès qu'un byte a pu être envoyé, la perte de la réponse définitive produit Indeterminate. Aucun renvoi automatique de A avec le même owner ; le caller n'entre pas en section critique.
• Cancel avant envoi est unsent ; après possible-send il ferme la session. Si un grant token a été parsé en parallèle, un release compensatoire exact-token borné est tenté.
• M, tous les E et les réponses malformed/oversized/unknown sont session-fatal. Un acquire possible-send non résolu devient Indeterminate.
• B est un refus certain de capacity, rendu immédiatement. Aucun retry interne ; le caller peut démarrer un nouvel acquire avec nouvel owner et backoff applicatif.
• Les releases explicites/compensatoires ne retentent l'exact token que pendant 5 secondes absolues depuis call/enqueue. R réussit, N signifie absent ou non courant ; sans réponse finale, erreur, jamais succès supposé.
• Ticket n'est rendu qu'avec un temps conservateur positif suffisant pour le work budget. Un travail de plus de 250 s est unsupported avant envoi.
• Le fencing DB par token est obligatoire : dans la même transaction, rejeter token <= stored_high_water, mettre à jour high-water et effectuer le business write avant commit/rollback puis release.

Options de sécurité (Token · TLS) ​

Toutes les options sont facultatives. token doit correspondre au client_tokens du serveur, et TLS propose quatre modes : désactivé / magasin de confiance système / CA spécifiée / vérification ignorée (test uniquement).

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" | chemin vers un fichier CA */
};
ticketing_result error;
ticketing_broker *broker = ticketing_connect_with(addrs, 3, &options, &error);

Vous pouvez générer le jeton, le TLS et la configuration de cluster côté serveur sur la page Déploiement du serveur Ticketing.