Netty - كيفية اختبار أرقام إصدار العميل / الخادم

Question

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

تم إعداد الرمز الموجود أدناه بشكل أساسي لإرسال "Hello World" الذي يطبعه الخادم بعد التحقق من الإصدار عند إنشاء الاتصال. على الأقل من الناحية النظرية ، في الواقع هذا لا يعمل تمامًا ؛)

لدي حاليًا:

Client.java

Genacodicetagpre

VersionClientHandler.java

Genacodicetagpre

BusinessLogicClientHandler.java

Genacodicetagpre

Server.java

Genacodicetagpre

VersionServerHandler.java

Genacodicetagpre

BusinessLogicServerHandler.java

Genacodicetagpre

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

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

Answer 1

لقد وجدت الحل !!!

كان هناك عدد من المشكلات.

في VersionClientHandler ، الكود الجديد هو:

Genacodicetagpre

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

في VersionServerHandler.java لدي الآن:

Genacodicetagpre

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

الاستنتاج

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

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

Answer 2

لم تذكر سبب الخطأ الذي تراه

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

Answer 3

لقد أنشأت مثالًا بسيطًا: https://github.com/boldt/netty-examples/

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

يُظهر رمز الترميز العام للخادم الإصدار على الفور.

على هذا النحو ، يمكنك إضافة معالج مصادقة إلى المسار خلف معالج الإصدار.

Answer 4

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

يجب أن يظل BusinessLogic Handler قيد الإعداد باعتباره الأخير.فقط كن على علم بأن أيًا من معالجاتك يقوم ببعض عمليات الحظر التي يجب أن تفكر في إضافة ExecutionHandler أمامه للتأكد من أن مؤشر ترابط ioworker سيتم حظره وبالتالي جعل الخادم الصغير غير مسؤول.