.NET 4.5 WebSockets vs SignalR

我已经看到了asp.net MVC聊天应用程序的signalR vs html5 websockets,但它并没有100%的回答我的问题,因为它基于HTML5 WebSockets,微软可能已经用.NETSocket对象在.NET 4.5中扩展了它。

我想知道WebSocketfunction是否确实和SignalR一样,并且在WebSocket不可用时回退到长轮询? 毫无疑问,微软会采用与SignalR相同的技术来实现这一技术?

编辑:

对于其他人想知道这个,我发现这个评论最有助于理解的情况,为什么我会使用SignalR:

那么,他们不是真的。 直到现在,IIS和ASP.NET没有在支持的WebSocket中构build任何内容,所以SignalR项目必须自己构build它。 现在,微软正在提供的pipe道SignalR可以轻松切换到使用微软的实施,除了或自己的,而不是。 SignalR是对实现细节的抽象,WebScockets类是实现细节

  1. 我想知道是否WebSocketfunction实际上做和SignalR一样的function,并且当WebSocket不可用时回退到长轮询?

    WebSockets是独立于其他通信技术的新协议。 从RFC

    该技术的目标是为基于浏览器的应用程序提供一种机制,这种应用程序需要与不依赖于打开多个HTTP连接例如使用XMLHttpRequest或长轮询 )的服务器进行双向通信。

  2. 毫无疑问,微软会采用与SignalR相同的技术来实现这一技术?

    不是,如果他们想要符合规格,他们不会。 当然,没有任何东西能够阻止微软开发类似于SignalR的更高级别的API,它将抽象出通信细节并提供优雅的回退。 然而,假设的API可能build立在WebSocket类之上而不是替代它。

我认为SignalR是要走的路,无论如何将成为.NET本身的一部分(并可能扩展/合并/取代web-sockets支持)。 它支持时使用networking套接字,并且当客户端轮询不一致时,就会发生一致的客户端轮询,所以这是一条路。

更新:

由于这个答案仍然是upvoted,值得一提的是SignalR现在正式成为ASP.NET的一部分。

检查http://asp.net/signalr

如果浏览器支持Web套接字,并且如果浏览器不支持WebSocket,则使用长轮询,SignalR使用OWIN将使用WebSocket连接。