Ticketing قواعد مطابقة الاستجابات (تنفيذ العميل)
بما أن الاستجابات قد تصل بترتيب مختلف عن الطلبات (تصل استجابة حصول انتظر عند حلول دوره)، يجب على العميل مطابقة الاستجابات بالطلبات وفق القواعد التالية — مخطط فصل (demultiplexing) يفرز الاستجابات المتداخلة على اتصال واحد إلى طلباتها.
| القاعدة | التفصيل |
|---|---|
| مفتاح المطابقة | رفض مؤكد بسبب queue/server capacity؛ إعادة Busy فورًا بلا retry داخلي |
| طلبات متعددة بنفس (op, المفتاح) | لا يجوز افتراض FIFO — يجب التحديد بالمُعرِّف. راجع الشرح أدناه |
| توقيت التسجيل | يُسجَّل المنتظر قبل إرسال الطلب (لمنع سباق تصل فيه الاستجابة أولًا) |
معالجة N/T | تُرجَع كقيم غير خطأ ("لم يكن موجودًا" / "انتهت المهلة") |
معالجة B | امتلاء الطابور — لا تُفشِل الطلب فورًا، بل أعد المحاولة بتراجع (backoff) ضمن ميزانية wait |
معالجة M | حفظ address موجود في allowlist فقط كـleader hint ثم الإغلاق؛ لا owner/key لربطه بطلبات pending المرسلة |
معالجة L | تحديث leader hint فقط وإبقاء الاتصال؛ إشعار من الخادم لا استجابة |
E no_leader / E not_active / E auth_failed | إغلاق وتطبيق backoff حسب الخطأ؛ no_leader يلغي hint أيضًا |
E أخرى / استجابة غير معروفة | غير قابل للربط، لذا connection-fatal؛ تصبح طلبات acquire المرسلة Indeterminate |
| استجابة بلا منتظر مطابق | عدم تطابق protocol/session: إغلاق. إن كانت A فأرسل exact token المعروف إلى reserved release lane |
لماذا المطابقة بالمُعرِّف لا بـ FIFO
حتى للـkey نفسها، يكتمل النجاح الفوري وانتظار queue ورفض B في أوقات مختلفة. كما تُرسل عدة keys عبر pipeline في اتصال واحد. لا تطابق FIFO؛ تحقق من echoed identifier وop وkey معًا.
الطلبات المُلغاة والأقفال اليتيمة
إذا حصل طلب ملغى على grant في الخادم فقد يبقى lock. بعد إرسال بايت واحد بلا استجابة نهائية تكون النتيجة Indeterminate. لا تعِد A بالـowner نفسه كاستعلام حالة. فقط إذا كان token قد parsed أرسل best-effort exact-token R؛ ويستعيد lease expiry أي grant مجهول.
لذلك يُغلق الاتصال بعد cancel لاحق للإرسال أو framing error. حذف pending وحده قد يترك استجابة يتيمة. Socket close ليس دليل release لـcommitted grant: exact-token R إذا عُرف، وإلا Indeterminate حتى lease expiry.