英文渣水平,大伙湊合著看吧,并不是逐字翻譯的……
這是微軟官方SignalR 2.0教程Getting Started with asp.net SignalR 2.0系列的翻譯,這里是第一篇:SignalR簡介
原文: Introduction to SignalR
ASP.NET SignalR是為簡化開發開發人員將實時web內容添加到應用程序過程而提供的類庫。實時web功能指的是讓服務器代碼可以隨時主動推送內容給客戶端,而不是讓服務器等待客戶端的請求(才返回內容)。
所有"實時"種類的web功能都可以使用SignalR來添加到你的ASP.NET應用程序中。最常用的例子有聊天室,但我們能做的比這要多得多。考慮以下情況:用戶需要不停的刷新網頁來看最新的數據;或者在頁面上通過實現長輪詢來檢索新數據(并顯示),那你就可以考慮使用SignalR來實現了。比如:儀表板及監視型應用程序;協作型應用程序(如多人同時對文檔進行編輯);作業進度更新及實時呈現表單等。
SignalR也適合新型的,需要從服務器上進行高頻率更新的web應用程序,例如實時游戲。這里有一個好例子:ShoorR。
SignalR提供了一個簡單的API用戶創建服務器到客戶端的遠程過程調用(RPC),可以方便地從服務器端的.Net代碼中對客戶端瀏覽器及其他客戶端平臺中的的JS函數進行調用。SignalR還包括了用于管理連接(例如:連接和斷開事件)及連接分組。
SignalR可以自動對連接進行管理。并讓你發送廣播消息到所有已連接的客戶端上,就像一個聊天室一樣。當然除了群發外,你也可以發送到消息到特定的客戶端。客戶端和服務器的連接是持久的,不像傳統的每次通信都需要重新建立連接的HTTP協議。
SignalR支持“服務器推送”功能,即服務器代碼可以通過使用遠程過程調用(RPC)來調用瀏覽器中的客戶端代碼,而不是當前在web上常用的請求-相應處理模型。
SignalR的應用可以使用服務總線,SQL SERVER或者Redis來擴展到數以千計的客戶端上。
SignalR是開源的,你可以通過GitHub訪問。
SignalR使用WebSocket傳輸方式——在可能的情況下。并且會自動切換到舊的傳輸方式(如HTTP長連接)。你當然可以直接使用WebSocket來編寫你的應用程序,但使用SignalR意味著你將有更多的額外功能而無需重新發明輪子。最重要的是,你可以將注意力關注在業務實現上,而無需考慮為舊的客戶端單獨創建兼容代碼。SignalR還能夠使你不必擔心WebSocket的更新,因為SignalR將會持續更新以支持變化的底層傳輸方式,跨不同版本的WebSocket來為應用程序提供一個一致的訪問接口。
當然,你可以創建只使用WebSocket傳輸的解決方案,SignalR提供了你可能需要自行編寫代碼的所有功能,比如回退到其他傳輸方式及針對更新的WebSocket實現來修改你的應用程序。
SignalR是對客戶端及服務器之間實時功能實現所需要的傳輸技術的抽象。SignalR首先以HTTP方式開始連接,并檢查WebSocket是否可用——如果確定,則升級到WebSocket的連接。WebSocket是SignalR最理想的傳輸方式,因為它可以最有效地利用服務器的內存,擁有最低的延遲及全面的底層功能(比如客戶端和服務器間的全雙工通訊),但它也有最嚴格的要求:服務器必須使用Windows Server 2012或Windows 8操作系統,同時.Net框架版本4.5及以上。如果不符合這些要求,SignalR將嘗試采用其他傳輸方式以進行連接。
使用何種傳輸方式取決于客戶端瀏覽器是否支持HTML5,否則將使用舊的傳輸方式。
下列傳輸類型都是基于Comet Web應用程序模型的,瀏覽器或客戶端將保持一個HTTP的長連接請求,服務器可以在客戶端沒有明確請求的情況下將數據推送到客戶端。
有關各種配置所支持的傳輸方式,請參見支持的平臺。(IE需要8以上,其他瀏覽器則是當前版本-1)
以下列表顯示SignalR如何決定使用何種類型進行傳輸。
如果以上條件中有任何一條不滿足,則使用長輪詢。跨域連接的詳細信息,請參閱如何建立跨域連接。
你可以通過啟用Hub日志記錄,并在瀏覽器的控制臺中查看應用程序使用何種傳輸方式。
要啟用日志記錄,添加以下命令到客戶端應用程序:
$.connection.hub.logging = true;
通過觀察控制臺中的日志記錄,你就能看到SignalR正在使用的傳輸方式。
協商傳輸方式需要使用一定的時間及服務器/客戶單的資源。如果客戶端環境已知,那么可以在啟動連接時指定傳輸方式來提高性能。下面的代碼演示如果已知的客戶端不支持任何其他協議時,直接在連接啟動時就使用Ajax的長輪詢:
connection.start({ transport: 'longPolling' });
如果你想要一個客戶端按照特定的順序進行傳輸方式的協商,你可以指定嘗試協商的順序。下面的代碼演示如何首先嘗試使用WebSocket并在失敗后直接使用長輪詢。
connection.start({ transport: ['webSockets','longPolling'] });
用戶指定傳輸的字符串常量定義如下:
SignalR API中包含兩中客戶端-服務器進行通信的模型:永久連接和集線器(Hubs)。
連接表示一個發送單個、分組或廣播消息的簡單終結點。持久性連接API(在.NET 代碼中由 PersistentConnection 類表示)可以讓開發人員直接訪問SignalR的底層通信協議。使用過基于連接API如WCF的開發人員將更熟悉連接通信模型。
集線器是基于API但級別更高一級的通信管道,它允許客戶端和服務器上互相直接調用方法。SignalR能夠奇妙的處理跨機器的調度,讓客戶端輕松的調用服務器上的方法,如同調用本地方法一樣,反之亦然。使用過基于遠程調用的AIP如.Net Remoting的開發人員將更熟悉集線器模型。使用集線器,你還可以將強類型的參數傳遞給方法并且對模型綁定。
下圖顯示了集線器、持久連接和用于傳輸的底層技術之間的關系。
當服務器代碼調用客戶端放的時,服務器將發送一個包含調用方法及參數(當對象作為方法參數時,將被序列化為JSON來發送)的數據包主動推送給客戶端。然后客戶端檢查接收到的方法名稱,并在客戶端定義方法中進行匹配查找,如果匹配成功,則執行方法并使用反序列化的對象作為方法參數。
你可以使用Fiddler之類的工具來監視方法的調用執行。下圖顯示了在Fiddler的日志中抓取到的一個從SignalR服務器發送到Web瀏覽器客戶端的方法。從集線器發起調用的方法為MoveShapeHub,被調用的方法為updateShape。
在這個例子中,集線器的名稱使用參數"H"標識,方法名稱使用參數"M"標識,發送給方法的參數對象使用參數"A"標識。生成該消息的應用程序是在高頻實時通訊教程中實現的。
大多數應用程序可以使用集線器的API,但在下列的情況下,你應當使用連接API:
作者:帕特里克·弗萊徹-帕特里克·弗萊徹是ASP.NET開發團隊的程序員,作家,目前正在SignalR項目工作。
新聞熱點
疑難解答