حدود واجهات المنصات وأثرها على البوت

كل منصة تداول تحدّ عدد الطلبات التي يرسلها برنامجك إلى واجهتها البرمجية (API) خلال فترة زمنية. البوت الذي يتجاهل هذه الحدود يتلقى رفضًا مؤقتًا، ثم قد يُحظر عنوانه لفترة، وقد يحدث ذلك وهو بحاجة إلى إغلاق مركز. فهم الحدود، والتعامل الصحيح مع الانقطاعات، وإعادة المحاولة بطريقة لا تكرر الأوامر، هي ثلاث مهارات تشغيلية أساسية لأي مشغّل.

الحدود

كيف تُحسب

المنصات تستخدم أساليب مختلفة، لكن الفكرة العامة واحدة: لكل طلب «تكلفة»، ولك رصيد من التكلفة يتجدد كل فترة.

مثال من وثائق Binance للسوق الفوري، حتى تاريخ كتابة هذا الدليل:

• لكل نقطة نهاية (Endpoint) «وزن» (Weight). الطلبات الثقيلة، مثل جلب دفتر أوامر عميق أو كل الأوامر المفتوحة لكل الأزواج، تستهلك وزنًا أكبر.
• الحدود مبنية على عنوان IP لا على مفتاح API. أي أن بوتين على الخادم نفسه يتشاركان الحد ذاته.
• كل رد يحمل رأسًا (Header) باسم X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter) يخبرك بالوزن المستهلك حاليًا.
• عند تجاوز الحد تعود الاستجابة برمز HTTP 429، ومعها رأس Retry-After بعدد الثواني الواجب انتظارها.
• الاستمرار في الإرسال بعد 429 يؤدي إلى حظر آلي للعنوان برمز HTTP 418، تتصاعد مدته مع التكرار من دقيقتين حتى 3 أيام.
• هناك أيضًا حد منفصل لعدد الأوامر المرسلة، وتجاوزه يعيد 429 كذلك.

منصات أخرى تستخدم نماذج مختلفة، مثل عدّاد يتناقص مع الزمن، أو حدود منفصلة لكل مفتاح. القاعدة: اقرأ صفحة الحدود في وثائق منصتك قبل كتابة أي سطر، ولا تفترض أن ما يعمل على منصة يعمل على أخرى.

من أين يأتي تجاوز الحدود عادة

1. الاستعلام المتكرر عن السعر. بوت يسأل عن السعر كل ثانية لعشرين زوجًا يرسل 1,200 طلب في الدقيقة. الأفضل الاشتراك في بث الأسعار عبر WebSocket، الذي لا يستهلك وزن الطلبات العادية.
2. جلب كل شيء في كل دورة. طلب كل الأوامر المفتوحة لكل الأزواج في كل دقيقة مكلف. اطلب ما تحتاجه فقط، أو استخدم بث بيانات الحساب (User Data Stream) لتصلك تحديثات الأوامر والأرصدة دون استعلام.
3. حلقات إعادة المحاولة. خطأ واحد يولّد إعادة فورية، فخطأ آخر، فإعادة أخرى. هذا أسرع طريق إلى الحظر.
4. عدة بوتات على عنوان واحد. كل واحد منها ضمن الحد، ومجموعها فوقه.

مثال توضيحي: ميزانية الطلبات

افترض حدًا قدره 6,000 وحدة وزن في الدقيقة (رقم توضيحي؛ راجع منصتك). خطة البوت:

52 من 6,000 يعني أقل من 1%. هذا هو الهدف: هامش واسع جدًا، حتى تبقى مساحة لعمليات الطوارئ مثل إلغاء كل الأوامر وإغلاق المراكز. اجعل البوت يقرأ رأس الوزن المستهلك ويبطئ تلقائيًا إن تجاوز مثلًا 50% من الحد.

الانقطاعات

أنواع الانقطاع

أخطر حالة: «لا أعرف إن نُفّذ الأمر»

البوت أرسل أمر شراء، ثم انقطع الاتصال قبل الرد. هناك احتمالان: الأمر لم يصل، أو وصل ونُفّذ. إن أعاد البوت إرساله مباشرة، فقد يملك الآن ضعف المركز المقصود.

الحل هو معرّف الأمر من جهة العميل. معظم المنصات تسمح لك بإرسال معرّف خاص بك مع كل أمر؛ في وثائق Binance يسمى newClientOrderId. البوت يولّد معرّفًا فريدًا قبل الإرسال ويحفظه. عند الشك، يستعلم عن الأمر بهذا المعرّف:

• إن وُجد الأمر: لا إعادة إرسال، وتُحدّث الحالة من المنصة.
• إن لم يوجد بعد مهلة كافية: يُرسل من جديد، بالمعرّف نفسه إن كانت المنصة ترفض المعرّف المكرر، فتكون أنت محميًا من الازدواج.

انقطاع بث الأسعار

اتصال WebSocket قد يبقى «مفتوحًا» دون أن تصل رسائل. البوت الذي يعتمد على آخر سعر مستلم سيتخذ قرارات على سعر قديم. القاعدة: سجّل وقت آخر رسالة، وإن مرّ عليه أكثر من مدة محددة، مثلًا 30 ثانية لزوج نشط، اعتبر البيانات قديمة، أوقف القرارات، وأعد الاتصال. بعض المنصات تقطع الاتصالات الطويلة دوريًا، وBinance مثلًا تحدد مدة صلاحية الاتصال الواحد، فيجب أن يتوقع البوت إعادة الاتصال كحدث عادي.

إعادة المحاولة

القواعد الأربع

1. ميّز بين ما يُعاد وما لا يُعاد. أخطاء الشبكة والمهلات و5xx قابلة لإعادة المحاولة بعد التحقق. أخطاء مثل «رصيد غير كافٍ» أو «كمية غير صالحة» لن تنجح بالتكرار؛ إعادتها تستهلك الحد فقط. سجّلها وأرسل تنبيهًا.

2. انتظار متزايد (Exponential Backoff). لا تعد المحاولة فورًا. انتظر ثانية، ثم ثانيتين، ثم 4، ثم 8، بحد أقصى مثل 60 ثانية.

3. عشوائية صغيرة (Jitter). أضف إلى كل انتظار جزءًا عشوائيًا، مثلًا ±20%. إن كان لديك عدة عمليات تعيد المحاولة معًا، فهذا يمنعها من الاصطدام بالحد في اللحظة نفسها مرة أخرى.

4. حد أقصى للمحاولات. بعد 5 محاولات فاشلة مثلًا، توقف وأرسل تنبيهًا. البوت الذي يحاول إلى ما لا نهاية يخفي المشكلة بدل أن يكشفها.

مثال توضيحي: جدول انتظار

إن احتوى الرد على Retry-After، فهو يتقدم على جدولك: انتظر المدة التي حددتها المنصة على الأقل.

الأولويات عند الضغط

حين يقترب البوت من الحد أو يعود من انقطاع، ليست كل الطلبات متساوية. رتّبها:

1. وضع أوامر وقف الخسارة المفقودة أو إغلاق المراكز.
2. إلغاء الأوامر القديمة.
3. مزامنة الحالة مع المنصة.
4. فتح صفقات جديدة، وهي آخر الأولويات، ويمكن تأجيلها بالكامل.

أمان المفاتيح

حدود الواجهة مرتبطة بأمان المفاتيح، لأن مفتاحًا مسرّبًا يستخدمه طرف آخر يستهلك حدودك أيضًا. القواعد الأساسية التي تتيحها معظم المنصات: صلاحية قراءة وتداول فقط دون سحب، تقييد المفتاح بعنوان IP الخادم، مفتاح منفصل لكل بوت، وتغيير المفاتيح دوريًا.

هذا المحتوى تعليمي وليس نصيحة استثمارية.

قائمة مراجعة

• قرأت صفحة الحدود في وثائق منصتك، وتعرف هل الحد على العنوان أم على المفتاح.
• ميزانية الطلبات أقل من 10% من الحد في التشغيل العادي.
• الأسعار وتحديثات الحساب عبر البث لا الاستعلام المتكرر.
• كل أمر يحمل معرّفًا من جهة العميل، ويُستعلم عنه قبل أي إعادة إرسال.
• إعادة المحاولة بانتظار متزايد وعشوائية وحد أقصى.
• 429 و418 يُحترمان، و418 يرسل تنبيهًا حرجًا.
• مفتاح بلا صلاحية سحب، ومقيّد بعنوان IP.

المصادر

• Binance Spot API Documentation، صفحة Limits (حدود الوزن، HTTP 429 و418، رأس Retry-After).
• Binance Spot API Documentation، أقسام Trading endpoints (المعامل newClientOrderId) وWebSocket Streams وUser Data Stream.