C# SocketAsynceventArgs يتوقف عن إطلاق الحدث المكتمل

Question

لقد لاحظت مشكلة في مكان. يبدو أنه يتوقف عن إطلاق النار. يمكن أن تطلق Saea نفسها بشكل صحيح واستبدالها في المجمع عدة مرات ، ولكن في النهاية ستتوقف جميع الحالات عن إطلاق النار ، ولأن الكود لاستبدالها في حمام السباحة يكون في معالج الأحداث ، فإن المسبح يفرغ.

ال الظروف التالية كما يبدو صحيحا:

1) يبدو أنه يحدث فقط عندما يرسل مقبس جانب الخادم البيانات إلى أحد العملاء المتصلين. عندما يتم توصيل الفئة نفسها كعميل ، لا يبدو أنها عطل.

2) يبدو أنه يحدث تحت الحمل العالي. يبدو أن عدد الخيط يتسلل حتى يحدث الخطأ في النهاية.

3) يبدو أن منصة اختبار تحت ضغط مماثل لا تصل إلى خلل. (إنها 20 رسالة فقط في الثانية ، وقد ثبت أن منصة الاختبار تصل إلى 20 ألفًا)

لن أكون قادرًا على لصق الكود المعقد إلى حد ما ، ولكن هنا وصف الكود الخاص بي:

1) الإلهام الرئيسي هو: http://vadmyst.blogspot.ch/2008/05/sample-code-for-tcp-server-using.html. يوضح كيفية توصيل منفذ الانتهاء باستخدام حدث ، وكيفية الحصول على رسائل مختلفة الحجم عبر اتصال TCP ، وما إلى ذلك.

2) لديّ مخزن مؤقت للبايت حيث يكون لدى جميع Saeas قطعة ، لا تتداخل.

3) لدي مجموعة كائن من Saeas ، استنادًا إلى عملية التوليف. هذا يرمي إذا كان المسبح فارغًا لفترة طويلة.

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

أدرك أنه من الصعب شرح هذا ؛ لقد تم تصحيحه ليوم وليل كامل. فقط آمل أن يكون شخص ما قد سمع بهذا أو لديه أسئلة أو اقتراحات مفيدة.

في الوقت الحالي ، أظن أن نوعًا من استنفاد الخيط ، مما يؤدي إلى عدم قدرة SAEAS على استدعاء الانتهاء. بدلاً من ذلك ، هناك نوع من المشكلات العازلة على المخزن المؤقت المنتهية ولايته.

Answer 1

لذلك ، يوم آخر من تصحيح الأخطاء وأخيراً لديّ تفسير.

1) لم يطلق SAEAS الحدث المكتمل لأنهم لم يتمكنوا من إرسال المزيد. تم الكشف عن ذلك بواسطة Wireshark ليكون بسبب إفراغ نافذة TCP. (TCP ZerowIndow)

2) كانت نافذة TCP تفريغ لأن طبقة الشبكات كانت تمرر حدثًا إلى أعلى المكدس الذي استغرق وقتًا طويلاً لإكماله ، أي أنه لا يوجد منتج/مستهلك بين طبقة الشبكة وواجهة المستخدم. وبالتالي ، سيتعين على الشبكة OP انتظار رسم الشاشة قبل إرسال ACK.

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

4) الحل على المدى القصير هو ببساطة التأكد من عدم وجود GUIs يحمل العرض. قد يكون الحل الأكثر قوة هو إنشاء منتج/مستهلك في طبقة الشبكة.