वर्तमान में परीक्षण चल रहा है: पूरा होने पर GitHub कोड खोला जाएगा।
Ticketing
दस्तावेज़
हिन्दी

Ticketing C/C++ लाइब्रेरी ​

GitHub

अभी तक आधिकारिक vcpkg रजिस्ट्री में पंजीकृत नहीं है — सबमिशन की आवश्यकताएँ सख्त हैं और पंजीकरण अभी भी प्रक्रिया में है। फ़िलहाल ऊपर दिए गए Github रिपॉज़िटरी को क्लोन करके स्वयं बिल्ड करें।

रिपॉज़िटरी ​

bash

उदाहरण ​

बुनियादी उदाहरण ​

Application startup पर एक broker बनाकर share करें। wait=0 queue बिना एक immediate attempt है, अधिकतम 255 सेकंड; lease 1–250 सेकंड। अंतिम minimum-work budget अनिवार्य है और 0 हो सकता है। Sub-second ऊपर round होते हैं; out-of-range या normalized lease से बड़ा budget send से पहले reject होता है, clamp नहीं।

c
#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 bounded best-effort release है। Result चाहिए तो explicit release API उपयोग करें। Token को उसी DB transaction में protected write fence करना अनिवार्य है।

जानने योग्य व्यवहार ​

  • एक request byte भी send हुआ हो सकता है तो final response खोने का परिणाम Indeterminate है। समान owner से A auto-resend नहीं; caller critical section में नहीं जाता।
  • Send से पहले cancel unsent; possible-send के बाद session बंद। साथ में grant token parse हो तो bounded compensating exact-token release।
  • M, हर E, malformed/oversized/unknown response session-fatal हैं। Unresolved possible-send acquire Indeterminate।
  • B निश्चित capacity rejection है और तुरंत लौटता है। Internal retry नहीं; caller application backoff के बाद नए owner से नया acquire कर सकता है।
  • Explicit/compensating release exact token को call/enqueue से पूर्ण 5 सेकंड तक ही retry करता है। R success, N absent/not current; final response न हो तो error, assumed success नहीं।
  • Positive conservative remaining time और पर्याप्त work budget पर ही Ticket मिलता है। 250 सेकंड से अधिक work send से पहले unsupported।
  • Token DB fencing अनिवार्य: उसी transaction में token <= stored_high_water reject, high-water update और business write, फिर commit/rollback और release।

सुरक्षा विकल्प (टोकन · TLS) ​

हर विकल्प वैकल्पिक है। token सर्वर के client_tokens से मेल खाना चाहिए, और TLS के चार मोड हैं: बंद / सिस्टम ट्रस्ट स्टोर / एक निर्दिष्ट CA / सत्यापन छोड़ें (केवल परीक्षण के लिए)।

c
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" | CA फ़ाइल का पथ */
};
ticketing_result error;
ticketing_broker *broker = ticketing_connect_with(addrs, 3, &options, &error);

आप सर्वर-साइड टोकन, TLS, और क्लस्टर कॉन्फ़िगरेशन Ticketing सर्वर परिनियोजन पृष्ठ पर जनरेट कर सकते हैं।