مهلات لا نهائية أو "فشل سريع" في بروتوكول الشبكة المخصص؟

Question

ضع في اعتبارك بروتوكول الشبكة المخصص.يمكن استخدام هذا البروتوكول المخصص للتحكم في الأجهزة الطرفية الآلية عبر شبكة LAN من محطة العمل المركزية القائمة على .NET.(إذا كان الأمر مهمًا، فإن الروبوت مشغول بنقل المصانع في بيئة إنتاج الرقائق).

• هناك طرفان فقط في المحادثة:محطة .NET واللوحة الطرفية الآلية
• يمكن للجانب الآلي تلقي الطلبات وإرسال الردود فقط
• يمكن لجانب .NET فقط بدء الطلبات وتلقي الاستجابات
• يجب أن يكون هناك دائمًا رد واحد بالضبط لكل طلب
• يمكن للطلبات اللاحقة أن تتبع مباشرة واحدة تلو الأخرى دون انتظار الرد، ولكنها لا تتجاوز أبدًا الحد الثابت للطلبات التي يتم تقديمها في وقت واحد (على سبيل المثال 5)

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

أحد أسبابي هو أنه في حالة حدوث أي فشل، يجب عليك "الفشل سريعًا" مهما كانت التكلفة، لأنه إذا حدث الفشل بالفعل على أي حال، فإن تكلفة الاسترداد تستمر في النمو بشكل متناسب مع الوقت الذي تقضيه في تلقي معلومات حول الفشل.لنفترض أنه بعد دقيقة واحدة على الشبكة المحلية (LAN)، يجب عليك بالتأكيد التوقف عن الانتظار واستدعاء بعض الإنذارات.

لكن حجته كانت أن الاسترداد يجب أن يتضمن بالضبط إصلاح ما فشل (في هذه الحالة استعادة اتصال الشبكة) وحتى إذا استغرق الأمر قضاء ساعات لمعرفة أن الشبكة مفقودة وتم إصلاحها، فيجب أن يستمر البرنامج في العمل بشفافية، على الفور بعد إعادة توصيل كابلات LAN.

لن أفكر جديًا أبدًا في البروتوكولات الخالدة، حتى هذه المناقشة.

أي جانب من الحجة هو الصحيح؟"تفشل بسرعة" أو "لا تفشل أبدًا"؟

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

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

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

Answer 1

أفضّل طريقة "الفشل السريع" الخاصة بك، ولكن أعتقد أنك اكتشفت أن هذه الطريقة تفضيلية للغاية.

تعمل أجهزة Cisco التي أعمل معها بشكل مشابه جدًا - فأنت ترسل طلبًا، وهم يستجيبون.(عبر telnet.) المشكلة هي عند فشل الشبكة:لقد فقدت اتصال TCP.ومع ذلك، لن يقوم أي من الطرفين بإغلاق هذا الاتصال حتى تتم محاولة إرسال البيانات، وبما أن جانب cisco نادرًا ما يفعل ذلك، فلن يتم إغلاقه أبدًا.والأسوأ من ذلك، أنه لا يمكنك الحصول إلا على اتصال واحد في كل مرة، لذلك إذا حدث فشل في الشبكة، فسيتم حظرك.(يمكن إعادة ضبطها، لكن الأمر مجرد متاعب.)

الآن ، لاختبار اتصال الشبكة ، تحتاج إلى نوع من ping ، فقط "هل ما زلت هناك؟" - العديد من البروتوكولات تفعل ذلك ، مثل AIM و IRC.لكن هذه الأصوات تكلف عرض النطاق الترددي، اعتمادًا على عدد المرات التي ترسلها فيها.

إذًا، هل اكتشاف الأخطاء يستحق تكلفة عرض النطاق الترددي؟ما الحجم الذي يجب أن يكون عليه اختبار ping حقًا؟أود أن أقول إنه يجب أن تكون قادرًا على الوصول إلى أقل من 50 ثمانيًا/بينغ، ويمكنك تنفيذ الأمر ping مرة واحدة كل 10 ثوانٍ، أو 30 ثانية، أو دقيقة واحدة، أو شيء من هذا القبيل، أود أن أقول إن الأمر يستحق ذلك.كلما عرفت أن لديك مشكلة في وقت مبكر، كان ذلك أفضل.إذا كان بإمكان البرنامج نفسه بعد ذلك استخدام هذه الأصوات لمعرفة أنه فقد الاتصال وأعاد الاتصال تلقائيًا، فسأقول أن هذا رائع، على غرار "الكمبيوتر، عالج نفسك"، ويقلل من المتاعب للمشغل.

إذا كنت تستخدم TCP/IP، فيمكنه القيام بذلك تلقائيًا نيابةً عنك - راجع TCP Keepalives.وبدلاً من ذلك، يمكنك القيام بذلك ضمن بروتوكول التطبيق الخاص بك، كما تفعل AIM وIRC.

Answer 2

في السيناريو حيث...

• لقد أرسلت وحدة التحكم طلبًا
• لم يتلق الروبوت الطلب
• فشل الشبكة

...ثم تم إرسال الطلب، لكنه ضاع ولن يصل أبدًا.

لذلك، عند استعادة الشبكة، يجب على وحدة التحكم إعادة إرسال الطلب:لا يمكن لوحدة التحكم أن تنتظر الاستجابة إلى الأبد.