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访问。
ignalR使用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将尝试采用其他传输方式以进行连接。
服务器发送事件,也称为EventSource(如果浏览器支持服务器发送事件,基本上除了IE以外的浏览器都支持该功能)。
下列传输类型都是基于Comet Web应用程序模型的,浏览器或客户端将保持一个HTTP的长连接请求,服务器可以在客户端没有明确请求的情况下将数据推送到客户端。
Forever Frame(仅限于IE)Forever Frame将创建一个隐藏的IFrame,向服务器发送一个不会完成的请求。然后服务器不断地发送脚本到客户端并由客户端立即执行,即建立一个从服务器到客户端的单向的实时连接。而从客户端到服务器的连接则使用不同于该连接的其他连接。比如一个标准的HTML请求,为每次数据的发送都会创建一个新连接。
Ajax长轮询不会创建一个持久性连接,而是通过不断地发出对服务器的请求来进行轮询。在每次连接时等待服务器发出响应并关闭这次连接,然后立即发出新的请求。当然这种方式会在连接复位并重新连接时造成一些延迟。
有关各种配置所支持的传输方式,请参见支持的平台。(IE需要8以上,其他浏览器则是当前版本-1)
传输方式选择过程
以下列表显示SignalR如何决定使用何种类型进行传输。
IE8及更早的版本,使用长轮询。
如果配置了JSONP(即连接时jsonp参数设置为true),使用长轮询。
如果正在使用跨域的连接(即SignalR端点和页面不在同一个域中),则满足以下条件的,使用WebSocket:
客户端支持跨域资源共享(CORS),具体的详细信息请参阅CORS at
客户端支持WebSocket
服务器支持WebSocket
如果以上条件中有任何一条不满足,则使用长轮询。跨域连接的详细信息,请参阅如何建立跨域连接。
如果没有配置使用JSONP和连接不跨域,使用WebSocket,当然前提是客户端和服务器都支持WebSocket。
如果客户端或服务器不支持WebSocket,使用服务器发送事件。
如果服务器发送事件不可用,使用Forever Frame。
如果Forever Frame不可用,使用长轮询。
监控传输
你可以通过启用Hub日志记录,并在浏览器的控制台中查看应用程序使用何种传输方式。
要启用日志记录,添加以下命令到客户端应用程序:
nnection.hub.logging = true;
你可以通过启用Hub日志记录,并在浏览器的控制台中查看应用程序使用何种传输方式。要启用日志记录,添加以下命令到客户端应用程序:
nnection.hub.logging = true;
$.connection.hub.logging = true;
在IE中,按F12打开开发人员工具,单击控制台选项卡。
在Chrome中,按Ctrl+Shift+J打开控制台
通过观察控制台中的日志记录,你就能看到SignalR正在使用的传输方式。
协商传输方式需要使用一定的时间及服务器/客户单的资源。如果客户端环境已知,那么可以在启动连接时指定传输方式来提高性能。下面的代码演示如果已知的客户端不支持任何其他协议时,直接在连接启动时就使用Ajax的长轮询:
connection.start({ transport: 'longPolling' });
如果你想要一个客户端按照特定的顺序进行传输方式的协商,你可以指定尝试协商的顺序。下面的代码演示如何首先尝试使用WebSocket并在失败后直接使用长轮询。
connection.start({ transport: ['webSockets','longPolling'] });
用户指定传输的字符串常量定义如下:
webSockets
forverFrame
serverSentEvents
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可以在以下情况下使用:
需要指定发送消息的格式。
开发人员更喜欢使用消息传递和调度模型,而不是一个远程调用模型
现有的应用程序中正在使用消息传递模型,计划移植到SignalR上。
参考原文地址:http://www.asp.net/signalr/overview/getting-started/introduction-to-signalr