.NET 4.5中的Websockets

问题描述:

我想开发一个Web应用程序,在其中客户端调用服务器上的服务来执行一些涉及某些处理的操作。服务器将执行所有必要的处理,当更新的数据准备就绪时,它会将该数据推送到客户端。目前我正在考虑两种方法: - 1.在SignalR中使用ASP.NET WEB API 2.在.NET 4.5中将WebSockets与WCF结合使用。.NET 4.5中的Websockets

我的服务器将在Windows Server 2012上,但大部分我的客户将是IE 9,我认为不支持WebSockets的。

书面的SignalR文件如果WebSockets的支持是不存在在不改变应用程序的代码,它会自动下降到长轮询英寸这是否也受.NET 4.5中的WebSockets支持,或者我必须手动完成。意味着我是否必须在服务器上同时实现Pull方法和Push方法。

请指导我,我将遵循的方法。

在以后的使用情况下,我想使用PhoneGap的制作iOS,Android的& Windows Phone的移动应用程序来构建这个Web应用程序。

你可以用ASP.NET教程http://www.asp.net/signalr/overview/getting-started/tutorial-getting-started-with-signalr

启动后这个教程,你知道所有你需要知道的关于SignalR

+0

谢谢伊沃,但我想比较两种方法。 SignalR&WebSockets在.NET 4.5中。如果环境不支持WebSockets或者我不得不手动处理,.NET 4.5中的WebSockets是否也回退到长轮询。 – 2013-03-25 07:23:37

+0

有几个开源websocket库fo .net(http://*.com/questions/9537641/node-js-socket-io-vs-signalr-vs-c-sharp-websocket-server)看到未标记回答。据我所知,不像信号器那样倒退。 SignalR为旧版浏览器获得3或4次回退。另请参阅http://*.com/questions/9524591/net-4-5-websockets-vs-signalr – Ivo 2013-03-25 07:29:23

的WebSockets不会回落到longpolling(并没有真正的基本的东西合理)。 SignalR是对HTTP传输的更高层次的抽象,这就是为什么它执行回退和其他事情(如通过连接提供一个很好的编程模型)。如果您选择在ASP.NET上使用websockets(不确定WCF),您将针对原始套接字进行编程(这意味着读取/写入数组段等),并且很难做到这一点很不错。 SignalR会为你做这件事,并且如果websocket在客户端或服务器上不可用,它将回退到其他几个传输(永远帧,服务器发送的事件,longpolling)。

关于客户,如果您选择使用SignalR你需要使用SignalR客户端。我们只支持javascript和.NET(silverlight,windows phone 8,winrt,.NET 4和.NET 4.5)。有些人已经为其他平台(包括iOS和Android)编写了客户端,但我们并未对其进行维护,因此我无法说明它们的最新状态。

我建议你使用SignalR这样你就可以专注于应用程序逻辑,而不是使用WebSockets的低层次的编程模型搞乱。

+0

为什么不能通过SignalR中的Web套接字连接Windows Phone 8? – kooldave98 2013-12-06 23:58:48

+0

因为在windows phone 8中没有websocket API – davidfowl 2013-12-07 10:31:08

+0

@dfowler虽然有一个套接字API,所以这不是一个借口。 – John 2013-12-13 14:11:32

我可以确认后备自动工作。如果websockets传输不能使用,ServersentEvent传输将被使用..等等。最后一个传输协议是longpolling。

我们SignalR服务器是.NET 4.5框架的应用程序,在一个ASP.NET MVC应用程序使用托管的DLL 4.5在Windows 2012服务器上。应用程序池是ASP.NET 4.0。

  • Windows 8或Windows 2012服务器上的.NET 4.5客户端似乎使用websockets。
  • Windows 7计算机上的相同.NET客户端(即使安装了框架4.5)也会自动返回到serversent事件传输。

随着Signalr上的浏览器JavaScript客户端,类似的事情发生了:

  • 的Chrome/Safari浏览器/支持WebSockets的其他浏览器似乎使用WebSockets。
  • IE浏览器/其他浏览器不支持websockets,但相对较晚的版本似乎使用serversentevents。

从经验来看,serversentevents并不是很糟糕,因此如果没有使用websockets,那么肯定不会使用它作为反对使用signalR的唯一因素,因为好处很多。

希望这会有所帮助。