Ticketing C#-Bibliothek ​

Repository ​

Beispiel ​

Einfaches Beispiel ​

Einen Broker beim App-Start erstellen und teilen. wait=0 ist ein sofortiger Versuch ohne Queue, maximal 255 s; lease liegt bei 1–250 s. Das letzte Minimum-Work-Budget ist Pflicht und darf null sein. Teilsekunden werden aufgerundet; Werte außerhalb des Bereichs oder Budget über der normalisierten Lease werden vor dem Senden abgelehnt und nie geclampt.

using Ticketing;

var broker = TicketBroker.Connect("127.0.0.1:5225");
await broker.WaitReadyAsync(TimeSpan.FromSeconds(5));

await using var ticket = await broker.AcquireAsync(
    "key", TimeSpan.FromSeconds(5), TimeSpan.FromSeconds(30), TimeSpan.FromSeconds(2));
var token = ticket.Token;
// In the same DB transaction: verify/update token high-water and perform the business write.

Automatisches Close/Drop ist ein begrenzter Best-effort-Release. Wenn das Ergebnis zählt, die explizite Release-API nutzen. Der Token muss den geschützten DB-Write in derselben Transaktion fencen.

Wissenswertes zum Verhalten ​

• Sobald ein Request-Byte gesendet worden sein könnte, führt eine verlorene definitive Antwort zu Indeterminate. Kein automatisches A mit demselben Owner; der Caller betritt die Critical Section nicht.
• Cancel vor Send ist unsent; nach possible-send wird die Session geschlossen. Wurde gleichzeitig ein Grant-Token geparst, folgt ein begrenzter kompensierender exact-token Release.
• M, jedes E und malformed/oversized/unknown Responses sind session-fatal. Ungeklärte possible-send Acquires werden Indeterminate.
• B ist definitive Capacity-Ablehnung und kommt sofort. Kein interner Retry; der Caller kann mit App-Backoff und neuem Owner einen neuen Acquire starten.
• Explizite/kompensierende Releases versuchen exact token nur bis absolut 5 Sekunden ab call/enqueue. R ist Erfolg, N bereits weg/nicht aktuell; keine finale Antwort ist Fehler, nie angenommener Erfolg.
• Ticket gibt es nur bei positiver konservativer Restzeit und ausreichendem Work-Budget. Arbeit über 250 s ist vor Send unsupported.
• Token-DB-Fencing ist Pflicht: in derselben Transaktion token <= stored_high_water ablehnen, High-water und Business Write aktualisieren, dann commit/rollback und release.

Sicherheitsoptionen (Token · TLS) ​

Alle Optionen sind optional. Token sollte mit den client_tokens des Servers übereinstimmen, und TLS hat vier Modi: aus / System-Vertrauensspeicher / eine angegebene CA / Verifikation überspringen (nur für Tests).

var broker = TicketBroker.CreateBuilder()
    .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"))
    // .Tls(TlsMode.InsecureSkipVerify)
    .Connect();

Die serverseitige Token-, TLS- und Cluster-Konfiguration kannst du auf der Seite Ticketing-Serverbereitstellung erzeugen.