.NET بروتوكول الاتصالات في الوقت الفعلي في اتجاهين

Question

أحتاج إلى الحفاظ على اتصال بين الخادم والعملاء المتعددين حتى يتمكن العملاء من إرسال الأوامر ، وأحداث تشغيل الخادم. الخادم هو في الأساس لاعب موسيقى ، ويقوم العملاء بإرسال أوامر مثل "play ()" ، "Pause ()" ، "GetPlayLists ()" ، إلخ. يجب أن يكون الخادم الموجود على جانبه قادرًا على إخبار العملاء بأشياء مثل "Songed" أو "PlayerPaused". وأيضًا ، يجب أن يكون من الممكن إرسال بعض البيانات إلى وإلحاقها (مثل الأغنية الحالية ، صورة الألبوم ، قوائم التشغيل ، إلخ). يمكنني المضي قدمًا وإنشاء مقبس بنفسي وإنشاء بروتوكول خاص بي للتعامل مع جميع السيناريوهات المذكورة أعلاه ، لكن من المحتمل أن يكون شخص ما قد فعل هذا أمامي بالفعل ، لذا فإن ما أريده حقًا هو إطار عمل في الوقت الفعلي- الاتصال بين الخادم والعميل لـ .NET. لقد نظرت إلى XML-RPC على سبيل المثال ، لكن لست متأكدًا من كيفية التعامل مع "onclientsend" مع ذلك. وأيضًا ، إذا لم أكن مخطئًا ، فسيكون XML-RPC يشبه الراحة. لقد نظرت أيضًا إلى WCF ، لكن بما أنه ليس لدي خبرة في ذلك ، فلا أعرف من أين أبدأ ، وكيفية استضافة الخادم في تطبيق وحدة تحكم بسيطة.

مهم: يجب أن يكون العميل قادرًا على عدم .NET.
مهم: يجب أن يكون هذا ممكنًا للاتصال بـ Java (Android).
مهم: الأنظمة الأساسية هي Windows (الخادم والعميل) ، و Android (عميل).
مهم: لا يوجد تدفق من الصوت. ومع ذلك ، يجب إرسال الصور.

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

يحررالمشكلة هي أنه عند إرسال البيانات عبر مآخذ التوصيل ، لا يوجد ضمان (على الإطلاق!) بأن الحزم التي أرسلتها ستُقرأها الخادم في نفس الوقت. قد أرسل 50 ، ثم 100 ، ثم 50 بايت مرة أخرى ، ولكن قد يقرأ الخادم أنه كقطعة 200 بلي ، أو 100 ثم 100 ، مما يعني أنني بحاجة إلى إنشاء مخزن مؤقت ، اقرأ في الرسائل حتى أعرف بالتأكيد (هذا مؤكد (هذا هي المشكلة) بأنني تلقيت رسالة كاملة (ولا شيء أكثر).

Answer 1

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

الرسائل هي ببساطة فئات متسلسلة باستخدام XMLSerializer. يتم إنشاء الفصول من XSD.

Answer 2

Zeromq تبدو مناسبة لمشكلتك. يبدو أنك نفذت شيئًا مشابهًا لنفسك.

• مكتبة SuperSocket التي تعمل كإطار توافق.

• يحمل الرسائل عبر INPROC و IPC و TCP و MultiCast.

• قم بتوصيل N-to-N في أنماط Fanout و PubSub وخط الأنابيب وأنماط الطلب.

• بسرعة كافية للمنتجات المجمعة والحوسبة الفائقة.

• I/O غير المتزامن لتطبيقات تمرير الرسائل متعددة الأوساط القابلة للتطوير.

• مجتمع مفتوح المصدر كبير ونشط.

• أكثر من 20 لغة بما في ذلك C ، C ++ ، Java ، .NET ، Python.

• معظم الأنفاد بما في ذلك Linux و Windows و OS X.

• برنامج LGPL المجاني ، الدعم التجاري من قبل Imatix Corporation.

Answer 3

يجب أن تذهب إلى WCF: http://msdn.microsoft.com/en-us/netframework/aa663324.aspx

Answer 4

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