C# web通信解决方案

1.Socket

2.Socket and websocket(HTML5)

3.SignalR

一，简介

Signal 是微软支持的一个运行在 Dot NET 平台上的 html websocket 框架。它出现的主要目的是实现服务器主动推送（Push）消息到客户端页面，这样客户端就不必重新发送请求或使用轮询技术来获取消息。

可访问其官方网站：https://github.com/SignalR/ 获取更多资讯。

二，实现机制

SignalR 的实现机制与 .NET WCF 或 Remoting 是相似的，都是使用远程代理来实现。在具体使用上，有两种不同目的的接口：PersistentConnection 和 Hubs，其中 PersistentConnection 是实现了长时间的 Javascript 轮询（类似于 Comet），Hub 是用来解决实时信息交换问题，它是利用 Javascript 动态载入执行方法实现的。SignalR 将整个连接，信息交换过程封装得非常漂亮，客户端与服务器端全部使用 JSON 来交换数据。

ASP.NET signalr对ASP.NET开发者来说是一个新的程序库，它能让我们更加容易便捷地开发实时通信功能;

signalr允许客户端和服务器之间双向通信。服务器可以将内容推送到已连接的客户端。

signalr支持Web Sockets，遇到其他兼容旧的浏览器signalr会用其他技术支持"双向通信"(不要较真)。

signalr包括这些API:连接管理（例如，连接和断开连接的事件）、对连接分组、和访问功能授权。

signalr可以用来添加任何形式的“实时通信”功能到您的ASP.NET应用程序。聊天是经常被用来作为一个应用例子，当然你可以做更多的事情。

用户常常通过刷新网页来查看新数据，或者页面支持长轮询来检索新的数据，使用signalr机制中支持这个方式,但它更智能更强大友好。

SignalR同时支持新类型的网络应用情况:需要高频度从服务端更新的情况(如实时游戏、看看这个ShootR game.)

SignalR提供了更加便捷简单的API,

signalr会自动地使用websocket通信(只要条件允许),条件不满足的时候也会自动使用其他旧的传输方式。当然你可以直接让你的程序直接使用WebSocket.

使用signalr意味着原先你需要自己花精力做的工作不需要再自己做了,因为它已经为你做了。最重要的是，它会持续更新跟进WebSocket技术,所以你不用担心

协议变化这类事情.

　　signalr是对客户端和服务器之间通信方式的一个抽象。一个signalr启动时使用HTTP连接，然后当环境允许就会直接提升到WebSocket连接。
WebSocket是SignalR的理想通信方式，因为WebSocket使服务器的内存得到最有效的利用，同时WebSocket具有最低的延迟，并拥有最底层特征（如客户端和服务器之间的全双工通信），但WebSocket也有最严格的要求：WebSocket需要服务器使用Windows Server 2012或Windows 8，和.NET框架4.5。如果不能满足这些要求，signalr将尝试使用其他通讯方式进行连接。

下面的列表展示了SignalR决定使用具体哪种通信方式

  1. 如果浏览器<=Internet Explorer 8,用长轮询的方式
  2. 如果配置中指定了使用jsonp,则会使用长轮询的方式
  3. 如何需要创建跨域连接,将会如使用WebSocket,如果一下条件满足的话(否则用长轮询)
    1. 客户端支持WebSocket
    2. 服务端支持WebSocket
    3. 客户端支持Cross-Origin Resource Sharing,这个大家自己百度

建立一个通讯方式需要一定的时间和客户机/服务器资源。如果客户机的功能是已知的，那么通信方式在客户端连接开始的时候就可以指定。下面的代码片段演示了使用AJAX长轮询方式来启动一个连接，将如果我们知道该客户端不支持其他的协议的话:

connection.start({ transport: ‘longPolling‘ });

你可以指定一个替补方式,如果你想让客户端按照顺序尝试通讯方式的话.下面的代码片段展示了尝试使用WebSocket,如果失败直接使用长轮询。

connection.start({ transport: [‘webSockets‘,‘longPolling‘] });

指定将字符串常量定义如下：

  • webSockets
  • foreverFrame
  • serverSentEvents
  • longPolling

SignalR API包括两种模型(用于客户端和服务端的通信):持久连接模型(Persistent Connections)和集线器(Hubs)模型

　　一个连接代表一个简单的终结点(相当于单个收件人、被分组的、广播消息 而言)

持久连接API(在.NET代码中以PersistentConnection呈现),它使得开发人员便捷使用SignalR暴露的底层通讯协议

连接通信模型,对习惯于使用类似WCF的同学们比较熟悉.

　　集线器模型是一个建立于连接API的高级管道.SignalR处理夸机器便捷的调度问题易如反掌,它使得客户端调用服务端的方法简单得犹如调用本地方法一样.反之亦然.

使用Hubs模型,或许对那些使用过.net remoting的人来讲就很容易理解了.使用Hub还可以让你对强类型参数方法、model绑定成为易事.

　SignalR服务端组件可以被部署在一下的服务端和客户端操作系统中.注意使用WebSockets时,SignalR需要Windows Server 2012 或者Windows 8,

(WebSocket能够在Windows Azure Web Sites上使用,只要站点的.NET framework 版本达到4.5，且WebSocket能在站点的配置页面使用）

  • Windows Server 2012
  • Windows Server 2008 r2
  • Windows 8
  • Windows 7
  • Windows Azure

　当SignalR部署在IIS中，需要下面的版本支持。注意如果使用在我们自己的操作系统上，如开发所用的环境(Windows 8 or Windows 7)，所有版本的IIS和Cassini不应该被使用，因为这里有一个10同时并发的限制，因为连接是短暂、频繁重新建立的、且不会立即被dispose，所以很快就会达到限制。IIS Express可以被使用在一般的操作系统上。

　　同时注意SignalR使用WebSocket时，IIS 8 或者 IIS 8 Express是你需要的，服务器必须用Windows 8, Windows Server 2012, 或者更高，同时WebSocket必须在IIS中可用。你可以去之类看看如何开启IIS的WebSocket功能：IIS 8.0 WebSocket Protocol Support

  • IIS 8 或者IIS 8 Express.
  • IIS 7 和 7.5. 需要支持 extensionless URLs .
  • IIS 必须跑在集成模式下; 经典模式是不行的.
  • 我们的系统程序必须跑在完全信任的模式下.

　SignalR能够在很多客户端平台下运行，本节描述了客户端浏览器、桌面应用程序、Silverlight应用程序及手机设备在使用SignalR的需求。

1.浏览器

　　SignalR支持许多中种类的浏览器，尤其是最近浏览器的两个版本。

在浏览器中使用signalr的应用程序必须使用jQuery的版本>=1.6.4.

signalr可在以下浏览器中使用:

    • IE:8, 9, 10, and 11.现代桌面版和手机版也支持
    • Mozilla Firefox:所有版本,请允许我这么说
    • Google Chrome: 所有版本,请允许我这么说
    • Safari:所有版本,请允许我这么说
    • Opera: 所有版本,只支持WINDOWS版本
    • Android 浏览器
      • 浏览器协议需求
        通讯协议 Internet 
        Explorer        		 Chrome
        (Windows or iOS)        		 Firefox Safari 
        (OSX or iOS)        		 Android
        WebSockets 10+ current - 1 current - 1 current - 1 N/A
        Server-Sent Events N/A current - 1 current - 1 current - 1 N/A
        ForeverFrame 8+ N/A N/A N/A 4.1
        Long Polling 8+ current - 1 current - 1 current - 1 4.1

        2.桌面应用程序和Silverlight程序

        　　注意:有人在做supersocket,所以我们可以让它运行得更强大,一下是官方给出的图

        桌面应用程序和Silverlight程序通讯协议需求
        通讯协议 .NET application Silverlight
        Web Sockets Windows 8+ and .NET 4.5+ N/A
        Forever Frame N/A N/A
        Server-Sent Events .NET 4+ 5+
        Long Polling .NET 4+ 5+

        3.Windows Store和Windows Phone应用程序

        　　如上,我们可以借助第三方做事情

        Windows Store  和Windows Phone      通讯协议需求
        Transport Windows Store/ 
        .NET        		 Windows Store/ 
        JavaScript        		 Windows Phone/
        IE        		 Windows Phone/
        .NET
        WebSockets N/A Win8+ 8+ N/A
        Forever Frame N/A Win8+ 7.5+ N/A
        Server-Sent Events Win8+ N/A N/A 8+
        Long Polling Win8+ Win8+ 7.5+ 8+

        参考地址：http://www.cnblogs.com/humble/p/3856357.html

时间： 2024-08-26 00:00:51

C# web通信解决方案的相关文章

动手打造自己的跨语言异构模块通信解决方案

目前主流的跨语言异构模块通信方案有很多种,比如: 1.跨语言的RPC调用(Apache Thrift):它是Facebook贡献给Apache基金会的开源项目,旨在构建跨语言平台的通信方案.目前它支持非常多种语言,其中当然包括C/C++和Java.Thrift内置一个语言编译器,可以根据Thrift的语法规范,编译生成指定语言的RPC调用模块,功能也是非常的强大.Thrift的语法规范里面定义了数据类型.数据模块结构,有点类似WebService里面的WSDL文件.通过Thrift,我们就可以实

HTML5 WebSocket：下一次Web通信革命揭幕

让我们一起来了解HTML 5对当前Web通信的改变.HTML 5 Web Socket通过在Web上的一个单一Socket定义了一个全双工通信信道为Web通信带来了显著的改善. [51CTO译文]关于HTML 5的各种前沿技术应用51CTO已经报道过很多,比如HTML 5的视频音频元素.HTML 5 Web SQL Database.HTML5 File API以及如何从零开始构建一个HTML 5页面等等.这些都是HTML 5对当前Web开发标准技术的升级或扩展.今天,51CTO带您了解HTML

读《精通CSS：高级Web标准解决方案》

因为最近在看<精通CSS:高级Web标准解决方案>,做了一些记录. 因为很多开发人员对于XHTML2的开发不满,于是出现了WHATWG和W3C的分裂,WHATWG决定开发自己的规范,也就是HTML5,而W3C的XHTML2标准已被放弃,HTML5成为了W3C的正式标准.XHTML和HTML的区别就是XHTML严格遵守XML编码规定,浏览器会依据文档的MIME类型来解析文档,如果不遵循规范会导致错误,而HTML却是很宽松的. Doctype类型和浏览器模式,DTD(文档定义类型)是一组机器可读的

web通信之跨文档通信 postMessage

index.html <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>web通信之跨文档通信</title> <style> iframe {float:left;width:45%; height:200px; bor

《精通CSS：高级Web标准解决方案》学习笔记01

对我来说,CSS算得上是一个很难的东西.因为它不像JavaScript那么有趣,对记忆的要求太高,而我对浏览器兼容性.各种CSS Hack真的一点都不感冒.琐碎的.非理论化的知识,真的很烦人呐~ 鉴于国产CSS书籍基本都是辣鸡的现状,我在半年前动用某工作室的购书资金采购了一些技术书籍,这本广受好评的<精通CSS>也在其中.但是在阅读过后我深深的感觉到,如果说CSS本来已经是一种很琐碎的布局知识集合的话,那这本书只能说是更加琐碎了,因为这只是一本纯纯的经验分享.而且随着前端技术的快速发展,明显能

使用 PHP 消息队列实现 Android 与 Web 通信

需求描述很简单:Android 发送数据到 Web 网页上. 系统: Ubuntu 14.04 + apache2 + php5 + Android 4.4 思路是 socket + 消息队列 + 服务器发送事件,下面的讲解步骤为 Android 端,服务器端,前端.重点是在于 PHP 进程间通信. Android 端比较直接,就是一个 socket 程序.需要注意的是,如果直接在活动主线程里面创建 socket 会报一个 android.os.NetworkOnMainThreadExcept

【转】JavaScript之web通信

原文转自:http://cloudbbs.org/forum.php?mod=viewthread&tid=28773&page=1&extra=#pid180304 一.前言 1. comet技术 浏览器作为 Web 应用的前台,自身的处理功能比较有限.浏览器的发展需要客户端升级软件,同时由于客户端浏览器软件的多样性,在某种意义上,也影响了浏览器新技术的推广.在 Web 应用中,浏览器的主要工作是发送请求.解析服务器返回的信息以不同的风格显示.AJAX 是浏览器技术发展的成果,通

[HTML5_WebWorkers]HTML5 web通信（跨文档通信/通道通信）简介

一.简单概要 web通信(洋名:web messaging)是一种文档中独立的浏览上下文间的DOM不会被恶意的跨域脚本暴露数据分享方式. 得得得,术语啊什么的,比看到凤姐还头疼.有必要把上面一句话拆开讲: web通信是一种数据分享方式(有屁话之嫌): 通信的主体是“浏览上下文”(这是纳尼?): 哦,“浏览上下文”呢是“一个将 Document对象呈现给用户的环境”,你可以近似理解为平常我们看到的某个页面所处的环境: web通信不会有DOM被恶意暴露的危险: 目前应用比较多的就是iframe之间的

Web通信

客户在浏览器输入一个有效的url地址开始,浏览器会利用socket向url对应的web服务器发送一个TCP请求,这个请求成功一次就需要来回握三次手才能确定,成功以后,浏览器利用socket TCP连接资源向web服务器请求http协议,发送以后就等着Web服务器把Http返回头和Body发送回来,发回来后浏览器关闭Socket连接,然后做Http返回头和Body的解析工作,最后呈现在浏览器上的就是看到的页面了.所有一次完整的Web通信,Tcp连接需要三次握手,也就是来回三次方能确定一个Tcp请求