Ticketing C/C++ Library ​

Not yet registered in the official vcpkg registry — the submission requirements are strict and registration is still in progress. For now, clone the Github repo above and build it from source.

Repository ​

Example ​

Basic Example ​

Create one broker at application startup and share it. wait=0 is one immediate attempt without a queue and the maximum wait is 255 seconds; lease is 1–250 seconds. The final minimum-work budget is required and may be zero. Clients round sub-second values up and reject out-of-range values or a budget greater than the normalized lease before sending; they never clamp.

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

Automatic close/drop is a bounded best-effort release. Use the explicit release API when its result matters. The token must fence the protected database write in the same transaction.

Good to Know (Behavior) ​

• Once any request byte may have been sent, losing the definitive response yields Indeterminate. The client never automatically resends A with the same owner, and the caller must not enter the critical section.
• Cancellation before send is unsent; cancellation after possible send closes that session. If a grant token was parsed concurrently, the client attempts a bounded compensating exact-token release.
• M, every E, and malformed/oversized/unknown responses are session-fatal. Unresolved possible-send acquires become Indeterminate.
• B is a definitive capacity rejection and is returned immediately. There is no internal retry; the caller may later start a new acquire with a new owner and application-level backoff.
• Explicit and compensating release retry the exact token only within an absolute 5-second deadline from call/enqueue. R is success, N means already gone or not current, and no final response is an error—not assumed success.
• A Ticket is returned only with positive conservative time remaining and enough time for the required work budget. Work over 250 seconds is unsupported before send.
• The token is mandatory database fencing: in the same DB transaction, reject token <= stored_high_water, update the high-water mark, and perform the business write before commit/rollback and release.

Security Options (Token · TLS) ​

Every option is optional. token should match the server's client_tokens, and TLS has four modes: off / system trust store / a specified CA / skip verification (test only).

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" | path to a CA file */
};
ticketing_result error;
ticketing_broker *broker = ticketing_connect_with(addrs, 3, &options, &error);

You can generate the server-side token, TLS, and cluster configuration on the Ticketing Server Deployment page.