دوره آموزشی SignalR به زبان فارسی
بسم الله الرحمن الرحیم
دوره آموزشی SignalR به زبان فارسی
آموزش SignalR بخش سوم
بخش پنجم- شروع ایجاد پروژه SignalR
بخش ششم - مروری بر مفاهیم SignalR
بخش هفتم- ایجاد پروژه Chat با SignalR
بخش هشتم - ایجاد پروژه Chat با SignalR در ASP.NET MVC
بخش نهم- ساخت یک Timer سمت سرور با SignalR
بخش دهم - آموزش ساخت یک پروژه SignalR با SQLDepedency در ASP.NET MVC
بررسی کردن نقل و انتقال اطلاعات (Monitoring transports)
برای اینکه Event (رویدادهای) hub را در یک مرورگر بررسی کنید بایدlogging را فعال کنید، دستور زیر را اجرا کنید:
$.connection.hub.logging = true;
شما می توانید نقل و انتقالات را برنامه خود را به وسیله فعال کردن logging در hub و همچنین باز نمودن پنجره Console درون مرورگر خود مشخص کنید.
در مرورگر Internet Explorer ابزار Developer Tools را می توایند با زدن F12 باز کنید و به قسمت Console بروید.
در گوگل کروم Ctrl+Shift+J را بزنید تا به قسمت Console بروید.
با باز کردن Console و فعال کردن logging شما می توانید نقل و انتقالات انجام شده به وسیله SignalR مشاهده کنید.
مشخص کردن نقل و انتقالات (transport)
برای شروع یک مذاکر یا همان انتقال اطلاعات، مدت زمانی مشخص باید سپری شود و همچنین منابع کلاینت و سرور باید مورد استفاده قرار گیرند، مانند مباحث شبکه که برای انتقال اطلاعات باید فرستنده و گیرنده در نحوه ارسال و سرعت ارسال به تفاهم برسند در اینجا نیز همینطور است و اگر کلاینت بتواند به این توانایی برسد، یک نقل و انتقال می تواند شروع شود.
کد کوچک زیر نحوه شروع برقراری ارتباط با استفاده از روش Ajax Long Polling را به شما نمایش می دهد، در اینجا ما اینطور در نظر گرفتیم که کلاینت از هیچ روش انتقال دیگری پشتیبانی نمی کند.
connection.start({ transport: 'longPolling' });
همچنین شما می توانید یک ترتیب fallback مشخص کنید تا اگر کلاینت ناموفق بود به صورت مشخص و مرتب این تلاش را برای اتصال مجدد تکرار کند.
connection.start({ transport: ['webSockets','longPolling'] });
حال کدمان را کمی پیشرفته تر می کنیم. سعی می کنیم در ابتدا به وسیله WebSocket متصل شویم اگر نشد به روش Long Polling سویچ می کنیم.
اگر بخواهید می توایند در این پارامتر مقادیر زیر را جایگذاری کنید. این ها همان روش هایی است که در بخش دوم در مورد آن صحبت کردیم.
Connections and Hubs
آرام آرام به انتهای مباحث تئوری نزدیک می شویم.
اگر خاطرتان باشد در بخش اول مقاله گفتیم که روش وب یک روش سنتی در نحوه برقرار ارتباط است و به ازای هر درخواست یک اتصال یا Connections ایجاد و سپس قطع می شود. اما در SignalR ما یک اتصال دائم داریم. اگر کمی فکر کنید متوجه می شوید که غیر از ای ممکن نیست زیرا وقتی شما ارتباطتان با کلاینت قطع شود چطور می توانید او را از بقیه جدا کنید و یا اطلاعات منحصر به فردی برای او ارسال کنید پس باید او همیشه بشناسید و ارتباطتان قطع نشود تا بتوانید او را در هر زمانی که نیاز داشتید بروز رسانی کنید.
ما دو روش در SignalR API برای برقراری ارتباط داریم، روش اول اتصال دائم و روش دوم Hub است.
Connection
Connection (در این جا اسم مدل ارتباطی است) یک Connection یک endpoint ساده برای ارسال به یک گیرنده یا گروهی از گیرندگان و یا یک ارسال عمومی (broadcast) را ارائه می کند. یک Persistent Connection API (روش اتصال Connection با استفاده از API که به صورت دائمی ایجاد شود) این قابلیت را به شما می دهد که به صورت مستقیم به سطوح پایین پروتکل های ارتباطی که در SignalR مورد استفاده قرار می گیرد دسترسی داشته باشد، می توانم جمله ام به طور ساده اینطور بیان کنم "شما به برنامه نویسی سطح پایین شبکه دسترسی خواهید داشت". برای استفاده از این ویژگی می توانید از کلاس PersistentConnection استفاده کنید.
استفاده کردن از مدل ارتباطی Connections برای کسانی که با connection-based APIs (مثل WCF) کار کردند بسیار ساده خواهد بود، اما مشکلی نیست انشالله در همین دوره ما این مطالب را کامل بررسی می کنیم.
Hub
یک Hub در واقع یک high-level pipeline است که برروی Connection API قرار می گیرد و به کلاینت و سرور اجازه می دهد هر یک به صورت مستقیم با یکدیگر ارتباط داشته باشند.(تصویر زیر را مشاهده کنید)
SignalR اجازه می دهد کلاینت متدهای درون سرور را به سادگی مانند متدهای داخلی خودش فرخوانی کند و این ویژگی برای سرور نیز وجود دارد.
استفاده کردن از مدل ارتباطی Hub برای کسانی که از روش فراخوانی API ها به صورت Remote استفاده کردند، مانند .NET Remoting ساده خواهد بود.
با استفاده از Hub همچنین شما می توانید پارامترها را به صورت strongly typed به متدها انتقال دهید.
در مورد strongly typed در این مقاله توضیح داده ام.
معماری
شکل زیر نحوه انتقال اطلاعات و ارتباط مابین لایه های زیرین و لایه های Hubs وPersistent Connections را به خوبی نمایش می دهد.
هنگامی که کد سمت سرور یک متد را دورن کلاینت فراخوانی کند، یک بسته (packet) شامل نام و پارامترهای متدی که فراخوانی شده است ارسال می شود. هنگامی یک شی به صورت پارامتر انتقال داده می شود می بایست برای انتقال یافتن به وسیله JSON serialize شود.
نحوه serialize کردن اطلاعات را می توایند در این مقاله مطالعه کنید.
کلاینت نام متد را با متد تعریف شده در کد خودش (client-side) تطابق می دهد، اگر این تطابق وجود داشته باشد، متد ما درون کلاینت با استفاده از deserialize کردن مقادیر پارامتر اجرا خواهد می شود (ساده : اگر متد درخواستی سرور پیدا شود مقادیر deserialize می شود و کد اجرا می شود).
با استفاده از ابزارهایی شبیه Fiddler می توانید اطلاعاتی که نقل و انتقال پیدا می کنند را بررسی کنید.
تصویر زیر فراخوانی یک متد ارسال شده از سوی یک سرور SIgnalR را برای یک Browser در سمت کلاینت نمایش می دهد، این تصویر با استفاده از نرم افزار Fiddler و بخش Log این نرم افزار ثبت شده است.
آموزش Fiddler را می توانید در این مقاله بخوانید
در اطلاعات زیر فراخوانی متد از یک Hub به نام MoveShapeHub آغاز شده است، و متدی که ما شروع کردیم به فراخوانی آن updateShape نام دارد.
در مثال بالا، نام Hub با پارامتر H تعریف شده است (H ابتدای کلمهHub ) و نام متد با کلمه M مشخص شده است (M ابتدای کلمه Method) و داده ای که به متد ارسال شده است با کلمه A مشخص شده است.
در بخش بعد معماری و مثال ها را آغاز خواهیم کرد.