Ticketing C/C++ لائبریری
GitHubابھی تک سرکاری vcpkg رجسٹری میں رجسٹر نہیں ہوا — جمع کروانے کی شرائط سخت ہیں اور رجسٹریشن ابھی جاری ہے۔ فی الحال، اوپر دیے گئے Github ریپوزیٹری کو کلون کریں اور خود بلڈ کریں۔
ریپوزیٹری
مثال
بنیادی مثال
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 نہیں۔
#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 سے
Aauto-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 کرتا ہے۔
Rsuccess،Nabsent/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_waterreject، high-water update اور business write، پھر commit/rollback اور release۔
حفاظتی اختیارات (ٹوکن · TLS)
تمام اختیارات اختیاری ہیں۔ token کو سرور کے client_tokens سے میل کھانا چاہیے، اور TLS کے چار موڈز ہیں: بند / سسٹم ٹرسٹ اسٹور / ایک مخصوص CA / تصدیق چھوڑنا (صرف ٹیسٹ کے لیے)۔
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 سرور تعیناتی صفحے پر بنا سکتے ہیں۔