تشغيل عرض الرسومات على أنظمة متعددة، مع الحفاظ على المزامنة

Question

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

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

تم ترميز كل هذا في C# .Net.

عرض العميل هو تطبيق Windows Forms.يقبل الخادم اتصالات TCP، ثم يخدمها بطريقة دائرية، مع الاحتفاظ بساعة رئيسية لما يحدث.يرسل العملاء إشارة تقول "لقد وصلت إلى نقطة المزامنة 32" (أو 19، أو 5، أو أيًا كان) وينتظر حتى يقر الخادم ثم يمضي قدمًا.أو يمكن للخادم أن يقول "لا، عليك أن تبدأ من نقطة المزامنة رقم 15".

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

ثم تغيرت المواصفات

يحتاج العملاء الآن إلى الاستجابة للتعليمات في الوقت الفعلي تقريبًا من الخادم - ولم يعد برنامج رقص محددًا مسبقًا.سيقوم الخادم بإرسال التعليمات وسيتم إعداد برنامج الرقص بسرعة.لقد حصلت على مهمة ممتعة تتمثل في إعادة تصميم البروتوكول، وحلقات الخدمة، وتعليمات البرمجة.

تشتمل مجموعة الأدوات الخاصة بي على أي شيء موجود في صندوق أدوات .Net 3.5 القياسي.يعد تثبيت برنامج جديد بمثابة ألم في المؤخرة، حيث يمكن مشاركة العديد من الأنظمة (العملاء).

أنا أبحث عن اقتراحات بشأن الحفاظ على مزامنة العملاء (نوع من نظام الإغلاق؟UDP؟بث؟)، توزيع "برنامج الرقص"، أي شيء قد يجعل ذلك أسهل من ترتيب TCP التقليدي للعميل/الخادم.

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

اقتراحات؟آراء؟تكهنات الحمار البرية؟أمثلة على الكود؟

ملاحظة:قد لا يتم وضع علامة "صحيحة" على الإجابات (نظرًا لأن هذه ليست إجابة "صحيحة")، ولكن من المؤكد أن إجراء تصويت +1 للاقتراحات الجيدة.

Answer 1

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

التصميم الذي استقرنا عليه أخيرًا بعد قدر لا بأس به من الاختبارات تضمن وجود آلة "رئيسية" واحدة.في حالتك، سيكون هذا هو وجود واحد من عملاءك العشرين الذي يعمل كرئيس، ويتصل بالخادم عبر TCP.

يقوم الخادم بعد ذلك بإرسال سلسلة أوامر السلسلة بأكملها إلى هذا الجهاز الواحد.

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

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

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

الخادم "الرئيسي" هو الأصعب.في تنفيذنا، كان لدينا في الواقع نفس رمز العميل مثل الـ 19 الأخرى (كعملية منفصلة) وعملية "ترجمة" واحدة أخذت النقطة، وقسمتها إلى 20 قطعة، ونقلتها.لقد كانت الكتابة بسيطة إلى حد ما، وعملت بشكل جيد للغاية.