C # Web Communications solutions

1.Socket

2.Socket and WebSocket (HTML5)

3.SignalR

First, Introduction

Signal is a Microsoft-supported HTML WebSocket framework that runs on the Dot NET platform. The main purpose of this is to implement a server proactive push (push) message to the client page so that the client does not have to resend the request or use polling technology to obtain the message.

Access to its official website: https://github.com/SignalR/for more information.

Second, the realization mechanism

The implementation mechanism of SignalR is similar to. NET WCF or Remoting, and is implemented using a remote proxy. For specific use, there are two different purposes of interfacing:persistentconnection and Hubs, where Persistentconnection is a long-time Javascript poll (similar to Comet), Hub is used to solve the real-time information exchange problem, it is implemented using Javascript dynamic loading execution method. SignalR the entire connection, the information exchange process is very beautiful package, the client and the server side all use JSON to exchange data.

The ASP. NET SIGNALR is a new library for ASP, which makes it easier and more convenient to develop real-time communication functions.

SIGNALR allows two-way communication between the client and the server. The server can push content to the connected client.

SIGNALR supports web Sockets and encounters other older browsers signalr will support "two-way communication" (don't be serious) with other technologies.

SIGNALR includes these APIs: connection management (for example, connected and disconnected events), grouping of connections, and authorization of access capabilities.

SIGNALR can be used to add any form of "real-time communication" functionality to your ASP. Chatting is often used as an example of an application, and of course you can do more things.

Users often refresh the page to see new data, or the page supports long polling to retrieve new data, which is supported in the SIGNALR mechanism, but it is smarter and more powerful and friendly.

SIGNALR also supports new types of network applications: the need for high-frequency updates from the server (such as live games, see this SHOOTR game.)

SIGNALR provides a more convenient and simple API,

SIGNALR automatically uses WebSocket communication (as long as conditions permit), and other old transports are automatically used when the condition is not met. Of course you can directly get your program to use WebSocket directly.

Using SIGNALR means that the work you need to spend your energy on does not need to be done yourself, because it has been done for you. Most importantly, it will keep up to date with WebSocket technology, so you don't have to worry

The agreement changes such things.

SIGNALR is an abstraction of how clients and servers communicate with each other. An SIGNALR is started with an HTTP connection, and then is directly promoted to the WebSocket connection when the environment allows it.
WebSocket is the ideal means of communication for SIGNALR because WebSocket makes the most efficient use of the server's memory while WebSocket has the lowest latency and has the most underlying characteristics, such as full-duplex communication between the client and the server. But WebSocket also has the most stringent requirements: WebSocket requires the server to use Windows Server 2012 or Windows 8, and. NET Framework 4.5. If these requirements are not met, SIGNALR will attempt to connect using other means of communication.

The following list shows how SIGNALR decides which communication method to use

1. If the browser <=internet Explorer 8, use the long polling method
2. If using JSONP is specified in the configuration, a long polling method is used
3. How to create a cross-domain connection, such as using WebSocket, if the condition is met (otherwise with long polling)
1. Client Support WebSocket
2. Service-Side Support WebSocket
3. Client Support Cross-origin Resource sharing, this everybody own Baidu

Establishing a communication method requires a certain amount of time and client/server resources. If the function of the client is known, then the communication mode can be specified at the beginning of the client connection. The following code snippet demonstrates the use of an Ajax long polling method to start a connection, if we know that the client does not support other protocols:

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

You can specify a backup method if you want the client to try to communicate in order. The following code snippet shows an attempt to use WebSocket if the failure directly uses long polling.

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

Specifies that the string constants are defined as follows:

• webSockets

• foreverFrame

• serverSentEvents

• longPolling

SignalR API includes two models (for client and server communication): Persistent connection model (persistent Connections) and hub (Hubs) model

A connection represents a simple endpoint (equivalent to a single recipient, a grouped, broadcast message).

Persistent connection API (rendered in. NET code in Persistentconnection), which makes it easy for developers to use the underlying communication protocols exposed by SIGNALR

Connect to the communication model, familiar with students who are accustomed to using WCF-like.

The hub model is a high-level pipeline that is built on the connection API. SIGNALR handling of the machine convenient scheduling problem is easy, it makes the client invoke the service side of the method as simple as calling the local method. and vice versa.

Using the hubs model may be easy to understand for those who have used. NET Remoting. Using the hub also makes it easy for you to bind to strongly typed parameter methods and model bindings.

The SIGNALR server component can be deployed on both the server side and the client operating system. Note When you use WebSockets, SIGNALR requires Windows Server 2012 or Windows 8,

(WebSocket can be used on Windows Azure Web sites, as long as the site's. NET Framework version reaches 4.5 and websocket can be used on the site's configuration page)

• Windows Server 2012
• Windows Server R2
• Windows 8
• Windows 7
• Windows Azure

When SIGNALR is deployed in IIS, the following version support is required. Note If you are using an environment that is on our own operating system, such as development (Windows 8 or Windows 7), all versions of IIS and Cassini should not be used because there is a 10 concurrent limitation because the connection is ephemeral, frequently re-established, And will not be immediately dispose, so the limit will soon be reached. IIS Express can be used on a general operating system.

Also note that when SIGNALR uses WebSocket, IIS 8 or IIS 8 Express is what you need, the server must be in Windows 8, Windows Server 2012, or higher, and websocket must be in the IIS available in. You can go and see. How to turn on IIS WebSocket Features: IIS 8.0 WebSocket Protocol support

• IIS 8 or IIS 8 Express.
• IIS 7 and 7.5. Need to support extensionless URLs.
• IIS must run in Integrated mode; Classic mode is not possible.
• Our system programs must run in full trust mode.

SIGNALR is capable of running on many client platforms, and this section describes the needs of client browsers, desktop applications, Silverlight applications, and mobile devices to use SIGNALR.

1. Browser

SIGNALR supports many types of browsers, especially the two versions of the most recent browsers.

Applications that use SIGNALR in a browser must use the version >=1.6.4 of jquery.

SIGNALR can be used in the following browsers:

• IE:8, 9, ten, and 11. Modern desktop and mobile editions are also supported
• Mozilla Firefox: All editions, please allow me to say so
• Google Chrome: All editions, please allow me to say so
• Safari: All editions, please allow me to say so
• Opera: All editions, only Windows version supported
• Android Browser
  
  
  • 
    
    
    
    

    Browser protocol Requirements

    Communication Protocols	Internet Explorer	Chrome (Windows or IOS)	Firefox	Safari (OSX or IOS)	Android
    WebSockets	+	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. Desktop applications and Silverlight programs
    

    Note: Someone is doing a supersocket, so we can make it run more powerful, and it is the official given figure

    desktop application and Silverlight Program communication protocol requirements

    Communication Protocols	. 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 and Windows phone apps

    As above, we can do things with third parties.

    Windows Store and Windows Phone Communication protocol requirements

    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+

    
    
    
    
    
    Reference Address: http://www.cnblogs.com/humble/p/3856357.html

C # Web Communications solutions