خادم WCF اختبار اتصال الاتصال. بينغ ()؟

Question

استخدام التقنيات على النحو المحدد في:

http://msdn.microsoft.com/en-us/library/system.servicemodel.servicecontractttribute.callbackconmact.aspx.

أقوم بتنفيذ إعداد ServerPush ل API للحصول على إعلامات حقيقية من خادم الأحداث (بدون اقتراع). بشكل أساسي، يحتوي الخادم على طريقة تسجيل () و Unregisterme () والعميل لديه طريقة اتصال تسمى الإعلان (رسالة السلسلة) التي، من خلال آليات الاتصال في WCF، يمكن للخادم الاتصال. هذا يبدو انه يعمل جيدا.

لسوء الحظ، في هذا الإعداد، إذا كان الخادم يتعطل أو غير متاح خلاف ذلك، فلن يعرف العميل أنه يستمع فقط إلى الرسائل. يمكن أن يعني الصمت على الخط أي إعلانات أو قد يعني أن الخادم غير متوفر.

نظرا لأن هدفي هو تقليل الاقتراع بدلا من الفوري، لا مانع من إضافة طريقة Void Ping () على الخادم جنبا إلى جنب إلى جانب RegisterMe () و Unregisterme () الموجودة فقط لاختبار اتصال الخادم. اختبار هذه الطريقة بشكل دوري، أعتقد، تأكد من أننا لا نزال مرتبطا (وأيضا أنه لم يتم إسقاط أي إعلانات من خلال النقل، لأن هذا هو TCP)

ولكن هل طريقة Ping () ضرورية أم أن اختبار الاتصال هذا يتوفر خلاف ذلك كجزء من WCF افتراضيا - مثل ServerProxy.IsstillConnected () أو أي شيء. كما أفهمها، فإن حالة القناة ستعود فقط معيبة أو مغلقة بعد فشل Ping ()، ولكن ليس بدلا من ذلك.

2) من منظور أوسع، هل هذا نهج رد الاتصال الصلبة؟ هذا ليس ل http أو ajax - عدد العملاء المتصلين سيكونون قليلة (عشرات العملاء، كحد أقصى). هل هناك مشاكل خطيرة مع هذا النهج؟ نظرا لأن ذلك يبدو أن هذا مخاطرة خفيفة، كيف يمكنني تحديد عميل بطيء / ضار من حظر الخادم من خلال عدم معالجة قائمة انتظار رد الاتصال بسرعة كافية؟ هل هناك نوع من المهلة المحددة لاستعداد الاتصال الذي يمكنني ضبطه دون التأثير على العمليات الأخرى؟

Answer 1

نهجك يبدو معقولا، إليك بعض الروابط التي قد تساعد أو قد لا تساعد (أنها ليست ذات صلة بالضبط):

الكشف عن وفاة العميل في عقود دوبلكس WCF http://tomasz.janczuk.org/2009/08/performance-of-http-polling-duplex.html.

وجود بعض الشيكات الصحية المدمجة في بروتوكول التطبيق الخاص بك منطقية.

إذا كنت قلقا من العملاء الخبيث، ثم أضف إذن.

يحتوي الرابط الثاني الذي شاركته أعلاه بمظهر عينة من الخادم الفرعي، قد تكون قادرا على استخدام هذا الرمز. زوجين يمكن أن نشاهده - النظر في دفع الإخطارات عبر مكالمات ASYNC أو في مؤشر ترابط منفصل. وقم بتعيين sendtimeout على ربط TCP.

هذر

Answer 2

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

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

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

امل ان يساعد.

Answer 3

يمكنك استخدام خدمة ناشر / مشترك مماثلة للمرء الذي اقترحته Jouval:http://msdn.microsoft.com/en-us/magazine/cc163537.aspx.

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