التعامل مع انقطاع الاتصال وحدود الطلبات.

الخطوات مكتوبة

1. 0:00

   التعامل مع انقطاع الاتصال وحدود الطلبات.

   يوضح هذا الدرس كيفية التعامل مع انقطاع MT5 وحدود الطلبات: انتظار استعادة الخدمة، وإعادة الاشتراك في البث، وتكرار طلبات القراءة بأمان. نستخدم ردودًا فعلية من حساب تجريبي.

2. 0:19

   تحقق من الجلسة الحالية أولًا.

   افتح mt5.mrpc.pro واحتفظ بمفتاح API ومعرّف الطرفية المحفوظ. يعرض رد ConnectState المسجّل الحالة Connected، وتكون isConnected وisAlive وapiIsAlive جميعها true. الطرفية سليمة. انقطاع المتصفح أو فشل طلب واحد لا يعني وحده أنك تحتاج إلى إنشاء طرفية جديدة.

3. 0:45

   امنح الاستعادة التلقائية وقتها.

   يراقب MetaRPC سلامة الطرفيات ويحاول تلقائيًا استعادة الجلسات النشطة المؤهلة، مع الاحتفاظ بمعرّف الطرفية. على التطبيق إيقاف الأعمال المتأثرة مؤقتًا ومنح الخدمة وقتًا، بدل تكرار استدعاء Reconnect أو ConnectEx. افحص الحالة على فترات، ثم تحقق من الوصول إلى الحساب عبر AccountSummary قبل المتابعة. الاستعادة تحتاج وقتًا، ولا تتم فورًا بعد كل طلب فاشل.

4. 1:17

   عالج السبب المحدد.

   قطع الاتصال المتعمد، وانتهاء الجلسة، والتعليق، وبيانات الدخول غير الصحيحة، كلها تحتاج إلى الإجراء المناسب. اقرأ السبب وحدّث بيانات الدخول أو عالج مشكلة الحساب عند الحاجة. Reconnect وConnectByToken أداتان للاستعادة الصريحة، وليستا حلقة تكرار لكل طلب. إذا بقيت جلسة مؤهلة غير متاحة، أبقِ الأعمال متوقفة وأرسل للدعم رمز الخطأ ووقت حدوثه.

5. 1:48

   أعد اتصال WebSocket الخاص بالتطبيق.

   اتصال الطرفية وWebSocket التطبيق اتصالان مختلفان. عندما تنجح قراءة الحساب مجددًا، أغلق المقبس المعطل وافتح OnSymbolTick بالمعرّف المحفوظ ومفتاح API. أعد اشتراكات الرموز المطلوبة. تعرض رسائل EURUSD الفعلية قيم bid وask والطوابع الزمنية. تأكد من وصول بيانات جديدة وتجنب إنشاء بث مكرر. يمكن إبقاء البث السليم مفتوحًا.

6. 2:16

   تعرف على رد تحديد المعدل الفعلي.

   هذا رفض فعلي لطلب AccountSummary التقطناه باختبار قراءة محدود. يعني HTTP Status Code 200 أن API أعاد ردًا. يحتوي error غير الفارغ على TERMINAL_RATE_LIMIT_EXCEEDED، وتوضح الرسالة أن الاستدعاء لم يُنفذ. الحد المرصود هو ثلاثمئة استدعاء غير تداولي خلال دقيقة متحركة، يشترك فيه جميع مستخدمي الطرفية. راجع الحدود الحالية بدل تثبيت هذا العدد في الشفرة.

7. 2:48

   انتظر المدة التي يحددها الخادم.

   يحتوي error.properties في هذا الرد على زوج مفتاح وقيمة باسم RetryAfterSeconds، وقيمته 1. انتظر ثانية واحدة على الأقل، ثم أضف تأخيرًا عشوائيًا قصيرًا قبل إعادة القراءة. أوقف مؤقتًا أيضًا بقية العمليات التي تتشارك حصة الطرفية. إذا تكرر الرفض، استخدم مدة الانتظار الجديدة. ومع HTTP Status Code 429، التزم بترويسة Retry-After.

8. 3:18

   استأنف الطلبات تدريجيًا.

   بعد الانتظار تنجح القراءة الفعلية: HTTP Status Code 200، دون خطأ API، مع بيانات الحساب التجريبي. لا ترسل كل طلبات القراءة المتراكمة دفعة واحدة. خزّن المعلومات المتكررة مؤقتًا، ونسّق معدل الطلبات بين العمليات، واستخدم OnSymbolTick للأسعار الحية. بلوغ الحد يستدعي الانتظار، لا إعادة اتصال الطرفية.

9. 3:44

   اجعل إعادة المحاولة واضحة ومحدودة.

   مثال Python المرفق مخصص لـAccountSummary فقط. يكرر الطلب فقط عند رد صريح بالتحديد أو الانشغال يتضمن مدة انتظار صالحة، ويضيف تأخيرًا عشوائيًا ويتوقف بعد ثلاث محاولات. تُعاد الأخطاء الأخرى إلى المستدعي. احفظ بيانات الدخول في متغيرات البيئة. ضع سياسة منفصلة ومحدودة للانقطاعات، ولا تعمم مساعد القراءة على أوامر الاتصال أو طرق التداول.

10. 4:14

    احسم نتيجة الصفقة غير المؤكدة أولًا.

    إذا ضاع رد طلب تداول، فقد يكون الوسيط نفّذه بالفعل. الاستعادة التلقائية لا تخبرك بنتيجة تلك الصفقة. بعد عودة الوصول، افحص OpenedOrders وDealsHistory. استخدم تذاكر الأوامر والتنفيذ إن توفرت، وقارن الرمز والاتجاه والحجم والوقت. قد تتشابه الصفقات، لذا أبقِ الطلب غير المحسوم متوقفًا بدل إرساله مجددًا تلقائيًا.

11. 4:41

    أنه الجلسة بطريقة صحيحة.

    عندما تنهي الجلسة عمدًا، أوقف الاشتراكات واستدعِ Disconnect. أوقفنا البث التجريبي وفصلنا الطرفية، ولم نغير أي صفقة. تذكر: يتولى MetaRPC استعادة الطرفيات المؤهلة، ويستعيد التطبيق مقبسه عند الحاجة، وينتظر عند بلوغ الحدود، ويتحقق من نتائج التداول غير المؤكدة قبل إرسال صفقة أخرى.