I am new to Signal R and has followed some articles like
http://www.c-sharpcorner.com/UploadFile/abhijmk/what-why-and-how-about-signalr/
http://www.asp.net/signalr/overview/getting-started/introduction-to-signalr
and has stringently practice
http://www.asp.net/signalr/overview/getting-started/tutorial-getting-started-with-signalr
But while looking into What is SignalR ?, the author mentioned that " In case of non-HTML5 supported browsers it uses other techniques."
I am curious to know in detail about this.
From the official FAQ (https://github.com/SignalR/SignalR/wiki/Faq):
SignalR uses a fallback mechanism to connect the browser to the server. After an initial negotiation request the following transports are tried in order until a successful connection can be made:
WebSockets (if the both the server and browser indicate they can support websockets)
Server Sent Events, aka EventSource (if the browser supports Server Sent Events, which is basically all browsers except Internet Explorer)
Forever Frame (for Internet Explorer only)
Ajax long polling
WebSockets is the only true full-duplex connection transport. All other transports listed here use the technique/technology named for the incoming data from the server, and standard Ajax POSTs for sends from the client to the server.
Related
Can someone brief about the difference between these looking-similar techniques?
Websocket
Server sent events (SSE)
HTTP2's Server Pushing
I knew all these 3 are "pushing" response from server instead of requesting by the client.
At the first look, it seems all are same.I need to get more clarity about the differences.
Websockets: asynchronous communication in both directions. So far doesn't work well with HTTP/2, but efforts are ongoing to make it so. (For example WISH and websockets2-over-http2.)
SSE: server can notify the browser of events. Uses normal HTTP and works well even with HTTP/2. It's possible to emulate asynchronous communication in both directions with SSE by issuing notifications from client to server via regular POST requests, in HTTP/2 these requests go in the same socket with everything else for the same origin and therefore the cost of establishing a new connection can be avoided. However, there may be processing costs on the server side for processing a POST request which are greater than using native websockets.
HTTP/2 Push: absolutely unrelated to the two above, it is a mechanism for a server to push assets to the browser in advance. Possible application: sending CSSs and Javascripts while the PHP engine is creating the HTML. In theory, HTTP/2 Push and SSE can be combined to make events available to the browser without the initial round-trip delay.
Why http based on request/response? Why server can't push data with http to client directly and must has to be response of client request? In start of connection I know that client has to send request but why after that client must continue request/response/req/resp. long polling, comet, Bosh and other server pushing method also based on req/resp method and not solve the question.
All your problems ok! RFC 6455 defines the WebSocket protocol. HTTP 1.1 supports bi-directional TCP-like sockets that do not require you follow the request/reply pattern. The original spec had only UTF-8 character coding support, but now with modern browsers, binary data can be sent down the wire as well. Working with WebSockets presents a new manner of framing a web application but it's growing browser support makes it a viable option for modern websites.
Node.js is the easiest way to get into using WebSocket's with the Socket.IO library. Do check it out.
Can anyone let me know how SignalR works internally in a high level way?
I am guessing it is flushing the data using Response.Flush and at client side it is sending Ajax requests at certain intervals. Is it correct?
No, SignalR is an abstraction over a connection. It gives you two programming models over that connection (hubs and persistent connections). SignalR has a concept of transports, each transport decides how data is sent/received and how it connects and disconnects.
SignalR has a few built in transports:
WebSockets
Server Sent Events
Forever Frame
Long polling
SignalR tries to choose the "best" connection supported by server and client (you can also force it to use a specific transport).
That's the high level. If you want to see how each transport is implemented, you can look at the source code.
There's also client code for each transport:
https://github.com/SignalR/SignalR/tree/master/src/Microsoft.AspNet.SignalR.Client.JS
If you're asking about how the long polling transport works in particular:
It sends an ajax request to the server that's waiting asynchronously for a signal to respond. When there is a signal or the request times out, it returns from the server and sends another request and the process continues. (I left some details out about how the client it keeps track of what it saw so it doesn't miss messages)
Hopefully that answers most of your question.
#davidfowl has already answered the major portion. However, to provide some more details regarding the difference in behavior of transports, specifically between WebSocket and other transports; below are some points.
WebSocket is the only transport that establishes a true persistent, two-way connection between client and server. However, WebSocket is supported only by IIS 8 or above, and the latest versions of Internet Explorer, Google Chrome and Mozilla Firefox.
While Server Sent Events, Forever Frame and Long polling, all three follow a one-way communication, and are supported by most of the browsers.
I am using Firefox, but I'd like to know how browsers decide this in general.
It seems that when I access the same URL twice in a short amount of time, my browser tries to re-use the TCP same connection for both requests (this is called keep-alive). However, when I access two different URLs (but still served by the same server), the browser sometimes decides to open up a new connection for each request. Obviously, the browser does not use a one-connection-per-URL policy.
I am asking this because I am trying to implement a web service that uses long polling. I can imagine that a user might want to open this service in multiple tabs on the same browser. However, with keep-alive, the second long poll request does not get sent until the first one completes (at least in Firefox), because the browser is trying to shove both of them into the same socket, which I did not expect when I designed the service. Even if the browser implements pipe-lining, there is no way that I can respond to the second request before I respond to the first, because HTTP mandates that I complete the responses in order.
When using HTTP/1.1, by default, the TCP connections are left open for reuse. This is for better performance than starting a new connection per request. The connection can be reused but the connection could close at any time by any of the parties.
You should read HTTP1.1 and the part on persistent connections.
In your case it is not even using HTTP pipelining (not broadly supported) because the next request is sent after the response of the first.
The browsers have a connection pool and reuse it per hostname. Generally speaking, a browser should not reuse a single connection for multiple hostnames, even if those hostnames actually resolve to the same IP address.
Most browsers allow the user to configure or override the number of persistent connections per server; most modern browsers default to six. If Firefox is truly blocking the second request because there's already a connection active, this is a bug in Firefox and should be filed in their bug tracking system. But if such a bug existed, I think you'd see many sites broken.
Manytimes clients ask for features like instant messaging (IM) and other client-to-client (P2P) communication for their web apps. Typically how is this done in normal web browsers? For example I've seen demos of Google Wave (and Gmail) that are able to IM from a regular browser. Is this via HTTP? Or does XmlHttpRequest (AJAX) provide the necessary backend for such communication?
More than anything I wonder how can a server "wake up" the remote client, lets say for sending an IM? Or does the client have to keep "polling" the message server for new IMs?
Typically the browser will poll the server for new messages. One approach that is often done to make this more efficient is the 'long poll' (see also this link) - the server responds immediately if it has anything; otherwise, it waits, keeping the connection open for a while. If a message comes in, it immediately wakes up and sends it, otherwise it comes back with a 'nope, check back' after a few tens of seconds. The client them immediately redials to go back into the long-polling state.