البث مثل UDP مع موثوقية TCP
https://stackoverflow.com/questions/31572
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أنا أعمل على حل .net يتم تشغيله بالكامل داخل شبكة واحدة.عندما يقوم المستخدمون بإجراء تغيير على النظام، أريد إطلاق إعلان وجعل الجميع يسمعونه ويتصرفون وفقًا لذلك.هل هناك طريقة يمكننا من خلالها بث رسائل كهذه (مثل ما سيسمح لك UDP بفعله) مع الحفاظ على التسليم المضمون (مثل TCP)؟
هذا على شبكة صغيرة (30 عميلاً)، إذا كان ذلك سيحدث فرقًا.
المحلول
تحتاج جميع الألعاب تقريبًا إلى خصائص الاستجابة السريعة (وبدرجة أقل، خصائص عدم الاتصال) لـ UDP وموثوقية TCP.ما يفعلونه هو أنهم يبنون بروتوكولهم الموثوق به فوق UDP.يمنحهم هذا القدرة على إرسال الحزم إلى أي مكان وجعلها موثوقة بشكل اختياري أيضًا.
عادةً ما يكون نظام الحزم الموثوق به نظامًا بسيطًا لإعادة المحاولة حتى يتم الإقرار بالاعتراف به، وهو أبسط من بروتوكول TCP ولكن هناك بروتوكولات تتجاوز ما يمكن أن يقدمه TCP.
يبدو وضعك بسيطًا جدًا.من المحتمل أن تكون قادرًا على تقديم الحل الأنظف بنفسك - ما عليك سوى جعل كل عميل يرسل ردًا "لقد سمعتك" واطلب من الخادم الاستمرار في المحاولة حتى يحصل عليه (أو يستسلم).
إذا كنت تريد شيئًا أكثر، فمعظم مكتبات البروتوكولات المخصصة موجودة في لغة C++، لذلك لست متأكدًا من مدى استخدامها بالنسبة لك.ومع ذلك، فإن معرفتي هنا عمرها بضع سنوات - ربما تم نقل بعض البروتوكولات حتى الآن.همم...RakNet وenet هما مكتبتان C/C++ تتبادران إلى الذهن.
نصائح أخرى
يمكنك استخدام الانتشار للقيام بالتواصل الجماعي.
@epatel - أؤيد اقتراح SCTP (لقد قمت بالتصويت، لكن لا يمكنني التعليق بعد على الأشياء الإضافية هنا).
يتمتع SCTP بالعديد من الميزات والمرونة الرائعة.يمكنك تقسيم اتصالك فرعيًا إلى تدفقات متعددة، واختيار موثوقية كل منها وما إذا كان مرتبًا أم لا.وبدلاً من ذلك، مع الموثوقية جزئيا الملحق، يمكنك التحكم في الموثوقية على أساس كل رسالة.
البث ليس ما تريد.نظرًا لأنه من المحتمل أن تكون هناك أجهزة متصلة بهذه الشبكة ولا تهتم برسالتك، فيجب عليك استخدام البث المتعدد.على عكس رسائل البث، التي يجب إرسالها ومعالجتها من قبل كل عميل على الشبكة، يتم تسليم رسائل البث المتعدد فقط إلى العملاء المهتمين (أي أولئك الذين لديهم نية لتلقي هذا النوع المحدد من الرسائل والتصرف بناءً عليه).
إذا قمت لاحقًا بتوسيع نطاق هذا النظام بحيث يحتاج إلى التوجيه عبر شبكة كبيرة، فيمكن للبث المتعدد التوسع إلى ذلك، في حين أن البث لن يفعل ذلك، لذلك تحصل على فائدة قابلية التوسع التي قد تقدرها لاحقًا.وفي الوقت نفسه، يمكنك التخلص من الحمل غير الضروري في المحولات والأجهزة الأخرى التي لا تحتاج إلى رؤية رسائل "لقد تم تغيير شيء ما".
قد ترغب في النظر في آر إف سي 3208 “مواصفات بروتوكول النقل الموثوق به PGM”.
هنا هو الملخص:
البراغماتية العامة متعددة البث (PGM) هي نقل موثوق متعدد البث المتعدد
بروتوكول التطبيقات التي تتطلب أمرًا أو غير مرتبة ،
تسليم بيانات مكون من مصادر متعددة من مصادر متعددة إلى مصادر متعددة
مستقبلات متعددة.يضمن PGM أن يتلقى جهاز الاستقبال في المجموعة إما جميع حزم البيانات من عمليات الإرسال والإصلاحات ، أو يمكنه اكتشاف فقدان حزم البيانات غير القابل للاسترداد.يهدف PGM على وجه التحديد كحل عملي لتطبيقات البث المتعدد مع متطلبات الموثوقية الأساسية.هدف التصميم المركزي هو بساطة التشغيل مع الاهتمام الواجب لقابلية التوسع وكفاءة الشبكة.
يمكنك استخدام وسيط الرسائل، مثل ActiveMQ.
انشر رسائلك إلى موضوع ما واطلب من العملاء تسجيل اشتراكات دائمة في الموضوع، حتى لا تفوتهم أي رسائل حتى لو لم يكونوا متصلين بالإنترنت.
Apache ActiveMQ هو وسيط رسائل مكتوب في Java مع عميل JMS الكامل.ومع ذلك ، تم تصميم Apache ActiveMQ للتواصل على عدد من البروتوكولات مثل STOMP و OpenWire مع دعم عدد من العملاء المختلفين من اللغة.
يتضمن دعم النظام الأساسي للعميل c# و.net
يمكنك تنفيذ سلوكك المشابه لـ TCP في طبقة التطبيق.
على سبيل المثال، يمكنك إرسال بث UDP، ولكن بعد ذلك تتوقع ردًا من كل مضيف.إذا لم تتلق ردًا خلال X ثانية، فأرسل ردًا آخر وهكذا حتى تصل إلى نوع ما من العتبة.إذا تم الوصول إلى العتبة (أي.المضيف لم يستجب على الإطلاق)، ثم قم بالإبلاغ عن خطأ.
ومع ذلك، للقيام بذلك، ستحتاج إلى قائمة محددة مسبقًا من المضيفين لتوقع رد الردود منهم.
إنشاء خادم TCP.اطلب من كل عميل الاتصال.في بروتوكول TCP الخاص بك مع العملاء، قم بإنشاء كل حزمة ببادئة 2 بايت من الحجم الإجمالي للرسالة التالية.
ثم يتصل العملاء read(max_size=2) على المقبس لتحديد حجم الرسالة التالية، وبعد ذلك read(max_size=s) لجمع الرسالة.
تحصل على رسائل موثوقة ومرتبة وبسيطة.لا تحتاج إلى إطار مراسلة لهذا الإطار.
كنت قطعاً تريد أن تنظر في البث العام العملي:
بينما يستخدم TCP ACKs للاعتراف بمجموعات الحزم المرسلة (وهو أمر قد يكون غير اقتصادية على البث المتعدد)، يستخدم PGM مفهوم الاعترافات السلبية (NAKs).
لمزيد من ز-الغوص, ، المصطلح الذي تبحث عنه هو البث المتعدد الموثوق.نلقي نظرة أيضا على متعدد المسارات TCP.
ما يمكنك فعله هو أنه بعد البث عملاء بدء اتصالات TCP.بخلاف ذلك، عليك فقط الاحتفاظ بقائمة بجميع العملاء وبدء الاتصالات بكل عميل بنفسك.
أعتقد أن هناك ثلاثة خيارات، بشكل عام:
- بدلاً من بث UDP، يمكنك إنشاء كيان (سلسلة رسائل أو عملية أو خادم أو خدمة أو أي شيء موجود في الحل الخاص بك) يحتفظ بقائمة المشتركين ويرسل رسائل UDP أحادية البث إليهم.
- استخدم البث المتعدد UDP، ولكن سيتعين عليك كتابة نوع من الآلية التي من شأنها أن تعتني بالتسليم الموثوق به (على سبيل المثال، إعادة المحاولة، المهلات، وما إلى ذلك).وهذا يعني أيضًا أنه يجب عليك الحصول على رد من عملائك.
- إذا لم تكن خائفًا من بروتوكولات النقل التجريبية، فقد تبحث هنا للاقتراحات.,
يجب على Yoy إلقاء نظرة على مواصفات Norm (البث المتعدد الموثوق والموجه نحو NACK).باستطاعتك العثور معلومات عن نورم هنا.
تم تصميم بروتوكول NORM لتوفير نقل موثوق به من كائنات البيانات السائبة أو التدفقات عبر خدمات توجيه وإعادة توجيه البث المتعدد عن IP عام.يستخدم Norm آلية إقرار انتقائية وسلبية (NACK) لموثوقية النقل وتوفر آليات بروتوكول إضافية لإجراء جلسات متعددة الموثوق بها مع تنسيق محدود "مسبق" بين المرسلين والمستقبلات
إنها معروفة إلى حد ما في العالم العسكري.
لماذا تبني شيئًا من الصفر إذا كان بإمكانك استخدام المكتبة؟وخاصة بالنسبة لمثل هذا المشروع الصغير؟
حاول استخدام إمكاستر والذي يستخدم في حد ذاته رسائل البث المتعدد الموثوقة - PGM، وهو مكتوب بلغة .NET وبمصدر كامل.سوف تحصل على محرك حانة/فرعي لطيف مع إمكانية تصفية المواضيع بسهولة.أو يمكنك التعلم من التعليمات البرمجية حول كيفية القيام بذلك وإنشاء الامتداد الخاص بك عليه.
أعتقد أن الميزة الأكثر إزعاجًا في TCP في هذه السيناريوهات هي القدرة/طريقة فرز الحزم الواردة حسب ترتيبها الأصلي - مفهوم الدفق.لا يمكنك قراءة البايت حتى البايت قبل وصوله.
إذا كنت تستطيع العيش بدونه، فلديك فرصة الحصول على البروتوكول الخاص بك، سريعًا وموثوقًا، ولكن ليس لطلب الحزم!من المستحيل ببساطة إدارة كليهما، لأنه لا يمكنك طلب وحدات البايت الخاصة بك حتى تتلقى نسخة أخرى من الحزمة المفقودة، وهذه هي المقايضة الرئيسية.
قم بإجراء البث المتعدد RDP.
