This question already has answers here:
SignalR: Why choose Hub vs. Persistent Connection?
(5 answers)
Closed 8 years ago.
I have to implement the real time functionality in web application. I read about SignalR that it provides two mechanism for this:
Connection API
Hubs
I did not find any fruitful comparison between these two across different categories such as Performance, Reliable, Security etc. Can anyone provide which mechanism should be used?
Hub is a layer on top of Connection API. A Connection has all the logic to send/receive, connect, reconnect, raise connection errors. A Hub provides a way to send/receive strong typed messages.
Read more in http://asp.net/signalr
Related
How to create to clients and initially 'handshake' via a SignalR hub and then communicate directly browser to browser? I remember a similar solution on this in the previous version #damianedwards mentioned a few years back in a (ch9?) podcast but can't find it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm designing a web API that will give an opprtunity for clients(other apps) to push some work request, receive immediately some id of that work request and later receive the result of that work request.
What is the typical approach for such kind of interactions?
As providing the result of work request reminds me server push interaction I thought about SSE(server sent events) and webscoket technologies, inclinig to websockets(as client may use the same connection for all kind of requets and receive all kinds of response). Is it a good choice for my goal? and how this can be scaled?
The question is about whether websocket technology suits for the described approach of api design and if not I'm wondering what is a better approach. Is it a good choice for my goal?
A webSocket connection is very well suited for receiving results back at some indeterminate time in the future and it would be a recommended way to do this.
Other requests from the client to server can either be ajax calls or sent as webSocket messages, mostly depending upon whether there are other reasons to make the requests as ajax calls or not. If you already have an established webSocket connection, then it is a convenient, easy and fast way to communicate with the server.
Taking the individual parts of what you doing:
Pushing some work request (from client to server).
This can be done equally well via Ajax or webSocket. If there was no other reason to have an already established webSocket connection, then this would traditionally be an Ajax call.
receive immediately some id of that work request
This is actually a little easier to do with an Ajax request because Ajax is a request/response protocol so if you send the work request via Ajax, it would be trivial to get the ID back as the response to that Ajax request. You could also do it via webSocket, but webSocket is just a messaging protocol. When sending the work request to the server, you could send it via a webSocket (as mentioned previously). And, the server could then immediately send back the work ID, but the client would have to develop some way to correlate the work ID coming back with the previously sent request since those two messages would not have any natural connection to one another. One way that correlation could be done is to have the client generate a temporary ID or hash value when sending the initial request (it can literally be anything that is unique for that client such as a timestamp) and then the server would send that same temporary ID back when it sends the work ID. All this is trivial with a request/response protocol like HTTP/Ajax.
later receive the result of that work request
HTTP Polling, webSocket or SSE could all be used. Polling is obviously not particularly efficient. I know a webSocket would work perfectly for this and it would provide an open conduit for any other items the server wants to send to the client in a push fashion. SSE can also be used to solve this problem (pushing data to a client) though I don't personally have any experience with it.
How reliable is SignalR Backplane regarding to the question if all messages will reach all subscribed nodes? Is it using a reliable protocol underneath or are there chances that a message can get lost?
Obviously it can be that (for example) due to some network issues one node is down for some time. When it becomes reachable again, SignalR Backplane will deliver all intermediate messages. This is at least what I understand from davidfowl:
[...] This is VERY important! SignalR is NOT reliable messaging, it's a connection abstraction. We may buffer messages for longpolling but you cannot rely on the messages being there for ever. If you have important messages you need to persist, then persist them.
But how long is "forever" in this context? Can it be quantified/configured?
Are there other scenarios to consider if a reliable system is to be built on top of SignalR Backplane?
I have a server and a client program. I am updating the number of clients as and when a client comes. However I am unable to show which client has closed after closing. Can anybody help me? I am using socketdescriptor to keep track of clients present.
I am also having different types of clients for which I am using threading concept.
When a client arrives, a Server class inheriting QTcpServer accepts connection and passes it a requesthandler class that inherits QTcpSocket. In this I am calling thread class for defining different types of clients. Here I am calling a function that updats client number in GUI.
However when I close a connection I am unable to identify which client closed and thus unable to updat in client.
How to overcome this issue?
void QAbstractSocket::disconnected() [SIGNAL]
is the way to go.
if for some case the clients are on the same machine, they must identify at the server anyway (a unique id or the type of application it is).
that might be done with a initial message to "tell the server" what kind of client is connected. that stored in a QMap<QTcpSocket*, MyClientType> and you can determine wich client disconnected and wich type it was.
cheers
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.