متضمنات Azure SignalR Service

تم إنشاء خدمة Azure SignalR أعلى إطار عمل ASP.NET Core SignalR. كما أنه يدعم ASP.NET SignalR عن طريق إعادة تنفيذ بروتوكول بيانات ASP.NET SignalR أعلى إطار عمل ASP.NET Core.

يمكنك بسهولة ترحيل ASP.NET Core SignalR محلي أو تطبيق SignalR ASP.NET للعمل مع SignalR Service، من خلال تغيير بضعة أسطر من التعليمات البرمجية.

يصف الرسم التخطيطي البنية النموذجية عند استخدام SignalR Service مع خادم التطبيق الخاص بك.

كما تتم مناقشة الاختلافات بين تطبيق ASP.NET Core SignalR المستضاف ذاتيا.

اتصالات خادم التطبيق

يستمع خادم تطبيق ASP.NET Core SignalR المستضاف ذاتيا إلى العملاء ويربطهم مباشرة.

باستخدام SignalR Service، لم يعد خادم التطبيق يقبل اتصالات العميل المستمرة، بدلا من ذلك:

1. negotiate يتم عرض نقطة النهاية بواسطة Azure SignalR Service SDK لكل مركز.
2. تستجيب نقطة النهاية لطلبات تفاوض العميل وتعاد توجيه العملاء إلى SignalR Service.
3. يتصل العملاء بخدمة SignalR.

لمزيد من المعلومات، راجع اتصالات العميل.

بمجرد بدء تشغيل خادم التطبيق:

• بالنسبة إلى ASP.NET Core SignalR: تفتح Azure SignalR Service SDK خمسة اتصالات WebSocket لكل مركز إلى SignalR Service.
• بالنسبة إلى ASP.NET SignalR: تفتح Azure SignalR Service SDK خمسة اتصالات WebSocket لكل مركز إلى SignalR Service وواحد لكل تطبيق اتصال WebSocket.

العدد الأولي للاتصالات افتراضيا إلى 5 ويمكن تكوينه باستخدام InitialHubServerConnectionCount الخيار في SignalR Service SDK. لمزيد من المعلومات، راجع التكوين.

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

اتصالات الخادم متصلة باستمرار بخدمة SignalR. إذا تم قطع اتصال الخادم بسبب مشكلة في الشبكة:

• جميع العملاء الذين يخدمهم اتصال الخادم هذا قطع الاتصال. لمزيد من المعلومات، راجع نقل البيانات بين العميل والخادم.
• يعيد الخادم توصيل العملاء تلقائيا.

اتصالاتُ العميل

عند استخدام خدمة SignalR، يتصل العملاء بالخدمة بدلا من خادم التطبيق. هناك ثلاث خطوات لإنشاء اتصالات مستمرة بين العميل وخدمة SignalR.

1. يرسل العميل طلب تفاوض إلى خادم التطبيق.

2. يستخدم خادم التطبيق Azure SignalR Service SDK لإرجاع استجابة إعادة توجيه تحتوي على عنوان URL لخدمة SignalR ورمز الوصول المميز.

   • بالنسبة إلى ASP.NET Core SignalR، تبدو استجابة إعادة التوجيه النموذجية كما يلي:

     {
         "url":"https://test.service.signalr.net/client/?hub=chat&...",
         "accessToken":"<a typical JWT token>"
     }
     

   • بالنسبة ASP.NET SignalR، تبدو استجابة إعادة التوجيه النموذجية كما يلي:

     {
         "ProtocolVersion":"2.0",
         "RedirectUrl":"https://test.service.signalr.net/aspnetclient",
         "AccessToken":"<a typical JWT token>"
     }
     

3. بعد أن يتلقى العميل استجابة إعادة التوجيه، فإنه يستخدم عنوان URL ورمز الوصول للاتصال بخدمة SignalR.

لمعرفة المزيد حول ASP.NET Core SignalR، راجع بروتوكولات النقل.

نقل البيانات بين العميل والخادم

عند اتصال عميل بخدمة SignalR، يعثر وقت تشغيل الخدمة على اتصال خادم لخدمة هذا العميل.

• تحدث هذه الخطوة مرة واحدة فقط، وهي تعيين واحد إلى واحد بين اتصال العميل والخادم.
• يتم الاحتفاظ بتعيين في SignalR Service حتى يتم قطع اتصال العميل أو الخادم.

عند هذه النقطة، يتلقى خادم التطبيق حدثا بمعلومات من العميل الجديد. يتم إنشاء اتصال منطقي بالعميل في خادم التطبيق. يتم إنشاء قناة البيانات من العميل إلى خادم التطبيق، عبر SignalR Service.

ترسل SignalR Service البيانات من العميل إلى خادم تطبيق الاقتران. يتم إرسال البيانات من خادم التطبيق إلى العملاء المعينين.

لا تقوم SignalR Service بحفظ بيانات العملاء أو تخزينها، ويتم إرسال جميع بيانات العملاء المستلمة إلى الخادم أو العملاء المستهدفين في الوقت الفعلي.

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

الخطوات التالية

لمعرفة المزيد حول Azure SignalR SDKs، راجع:

• ASP.NET Core SignalR
• ASP.NET SignalR
• نماذج التعليمات البرمجية ASP.NET