I'm considering updating an existing site to use SignalR. My site polls a third party service for data changes, does some magic on it, and clients poll it once every few minutes to refresh their view with any updates.
SignalR seems like a great way to eliminate the polling from the client, but I want to know how SignalR handles dropped & reconnected connections, especially with regards to mobile web apps which may have been suspended for some time. Will it automatically negotiate and queue up any updates that were missed in the meantime, or does the client need to resynch from scratch in these cases? I looked but couldn't find any docs on this so guidance would be appreciated.
All this is definitely possible since the client keeps track of the last message id it saw. If it happened to miss messages, it'll get those the next time it goes back to the server (asking for all messages since the last one it saw).
By default the server side of SignalR stores messages in memory (and it purges those every few seconds), but you can change it to persist to some persistent store (see IMessageStore) if you're thinking about clients going offline and catching up.
You could even persist messages yourself in your own app logic while SignalR stores stuff in memory. It really depends on the application.
We haven't added any special support for mobile clients, but you can persist the message id in whatever local storage you need to for your mobile client.
Those details aren't very specific but what you want to do is all possible with SignalR.
Read Understanding and Handling Connection Lifetime Events in SignalR, especially these sections:
How to continuously reconnect - required to recover from a disconnected state;
How to notify the user about disconnections - so your app can not only inform the user, but detect state changes (disconnected, reconnecting, reconnected) to refresh your app's state in other ways.
That document was written in 2014 and basically obsoletes many of the wrong or incomplete StackOverflow SignalR-related questions/answers from the 2011-2012 era.
Related
I'm designing a database monitoring application. Basically, the database will be hosted in the cloud and record-level access to it will be provided via custom written clients for Windows, iOS, Android etc. The basic scenario can be implemented via web services (ASP.NET WebAPI). For example, the client will make a GET request to the web service to fetch an entry. However, one of the requirements is that the client should automatically refresh UI, in case another user (using a different instance of the client) updates the same record AND the auto-refresh needs to happen under a second of record being updated - so that info is always up-to-date.
Polling could be an option but the active clients could number in hundreds of thousands, so I'm looking for a more robust and lightweight (on server) solution. I'm versed in .NET and C++/Windows and I could roll-out a complete solution in C++/Windows using IO Completion Ports but feel like that would be an overkill and require too much development time. Looked into ASP.NET WebAPI but not being able to send out notifications is its limitation. Are there any frameworks/technologies in Windows ecosystem that can address this scenario and scale easily as well? Any good options outside windows ecosystem e.g. node.js?
You did not specify a database that can be used so if you are able to use MSSQL Server, you may want to lookup SQL Dependency feature. IF configured and used correctly, you will be notified if there are any changes in the database.
Pair this with SignalR or any real-time front-end framework of your choice and you'll have real-time updates as you described.
One catch though is that SQL Dependency only tells you that something changed. Whatever it was, you are responsible to track which record it is. That adds an extra layer of difficulty but is much better than polling.
You may want to search through the sqldependency tag here at SO to go from here to where you want your app to be.
My first thought was to have webservice call that "stays alive" or the html5 protocol called WebSockets. You can maintain lots of connections but hundreds of thousands seems too large. Therefore the webservice needs to have a way to contact the clients with stateless connections. So build a webservice in the client that the webservices server can communicate with. This may be an issue due to firewall issues.
If firewalls are not an issue then you may not need a webservice in the client. You can instead implement a server socket on the client.
For mobile clients, if implementing a server socket is not a possibility then use push notifications. Perhaps look at https://stackoverflow.com/a/6676586/4350148 for a similar issue.
Finally you may want to consider a content delivery network.
One last point is that hopefully you don't need to contact all 100000 users within 1 second. I am assuming that with so many users you have quite a few servers.
Take a look at Maximum concurrent Socket.IO connections regarding the max number of open websocket connections;
Also consider whether your estimate of on the order of 100000 of simultaneous users is accurate.
I would like to ask, if it is a good idea to use SinglR just for knowing if the current user now online or not?
For example I have an small website with log in system, and some where on the side i would like to show the logged in members.
Is this a good idea to use signalr for that?
And if it the case should I then on each page start the connection with hub? (In this case when user navigates on the pages, will be the ReConnected method called on hub, or OnDisconnected and OnConnected)?
I'm just starting with signalr, so curious what ppl think.
You could use SignalR though there might be better methods to do this. So when a user logs in, logs out or becomes inactive - you would have some sort of message being sent from the client to the server that indicates the change in status. You can store that information in a temporary database and whenever a value in the database changes you can use SignalR to relay that information to all the connected clients.
Signalr will get reconnected when the user moves from one page to another page. Whenever a user logs into a website the user security details will be persisted in a cookie assuming you are using Cookiebase authentication. So till the user logs out or session timesout the cookie will be active. So there is no real need for Signalr here.
I have been investigating the same thing. From my research, I would say that you COULD do this, but I'm on the fence of whether it's the best way to go about it. I would expect a LOT of disconnecting, connecting and reconnecting. If you're persisting this data in a database, you should anticipate a lot of database traffic. if you're only on a single server though, you could just persist this in memory.
Something to also note is that the ConnectionId changes with each page refresh. At first, I thought that was dumb because I wanted the connection id to be consistent so i could keep a handle on a user with it. However, if you open a link in a new tab and then close one of them, you have to still keep the other connection in storage. If the id was the same you would remove it on disconnect even though the other tab was open, so your user would incorrectly be marked as offline.
However, the other issue that i'm thinking about is that if you're just browsing around the site in a single tab, you will disconnect for a split second between each page load. So you might run into connection consistency issues with that.
I'd say online presence with signalr is more common to be used for a chat room or game lobby. So I'd say this is possible, but whether it's a good solution -- i'm unsure.
Most if not all of the NSB examples for ASP.NET (or MVC) have the web application sending a message using Bus.Send and possibly registering for a simple callback, which is essentially how I'm using it in my application.
What I'm wondering is if it's possible and/or makes any sense to handle messages in the same ASP.NET application.
The main reason I'm asking is caching. The process might go something like this:
User initiates a request from the web app.
Web app sends a message to a standalone app server, and logs the change in a local database.
On future page requests from the same user, the web app is aware of the change and lists it in a "pending" status.
A bunch of stuff happens on the back-end and eventually the requests gets approved or rejected. An event is published referencing the original request.
At this point, the web app should start displaying the most recent information.
Now, in a real web app, it's almost a sure thing that this pending request is going to be cached, quite possibly for a long period of time, because otherwise the app has to query the database for pending changes every time the user asks for the current info.
So when the request finally completes on the back-end - which might take a minute or a day - the web app needs, at a minimum, to invalidate this cache entry and do another DB lookup.
Now I realize that this can be managed with SqlDependency objects and so on, but let's assume that they aren't available - perhaps it's not a SQL Server back-end or perhaps the current-info query goes to a web service, whatever. The question is, how does the web app become aware of the change in status?
If it is possible to handle NServiceBus messages in an ASP.NET application, what is the context of the handler? In other words, the IoC container is going to have to inject a bunch of dependencies, but what is their scope? Does this all execute in the context of an HTTP request? Or does everything need to be static/singleton for the message handler?
Is there a better/recommended approach to this type of problem?
I've wondered the same thing myself - what's an appropriate level of coupling for a web app with the NServiceBus infrastructure? In my domain, I have a similar problem to solve involving the use of SignalR in place of a cache. Like you, I've not found a lot of documentation about this particular pattern. However, I think it's possible to reason through some of the implications of following it, then decide if it makes sense in your environment.
In short, I would say that I believe it is entirely possible to have a web application subscribe to NServiceBus events. I don't think there would be any technical roadblocks, though I have to confess I have not actually tried it - if you have the time, by all means give it a shot. I just get the strong feeling that if one starts needing to do this, then there is probably a better overall design waiting to be discovered. Here's why I think this is so:
A relevant question to ask relates to your cache implementation. If it's a distributed or centralized model (think SQL, MongoDB, Memcached, etc), then the approach that #Adam Fyles suggests sounds like a good idea. You wouldn't need to notify every web application - updating your cache can be done by a single NServiceBus endpoint that's not part of your web application. In other words, every instance of your web application and the "cache-update" endpoint would access the same shared cache. If your cache is in-process however, like Microsoft's Web Cache, then of course you are left with a much trickier problem to solve unless you can lean on Eventual Consistency as was suggested.
If your web app subscribes to a particular NServiceBus event, then it becomes necessary for you to have a unique input queue for each instance of your web app. Since it's best practice to consider scale-out of your web app using a load balancer, that means that you could end up with N queues and at least N subscriptions, which is more to worry about than a constant number of subscriptions. Again, not a technical roadblock, just something that would make me raise an eyebrow.
The David Boike article that was linked raises an interesting point about app pools and how their lifetimes might be uncertain. Also, if you have multiple app pools running simultaneously for the same application on a server (a common scenario), they will all be trying to read from the same message queue, and there's no good way to determine which one will actually handle the message. More of then than not, that will matter. Sending commands, in contrast, does not require an input queue according to this post by Udi Dahan. This is why I think one-way commands sent by web apps are much more commonly seen in practice.
There's a lot to be said for the Single Responsibility Principle here. In general, I would say that if you can delegate the "expertise" of sending and receiving messages to an NServiceBus Host as much as possible, your overall architecture will be cleaner and more manageable. Through experience, I've found that if I treat my web farm as a single entity, i.e. strip away all acknowledgement of individual web server identity, that I tend to have less to worry about. Having each web server be an endpoint on the bus kind of breaks that notion, because now "which server" comes up again in the form of message queues.
Does this help clarify things?
An endpoint(NSB) can be created to subscribe to the published event and update the cache. The event shouldn't be published until the actual update is made so you don't get out of sync. The web app would continue to pull data from the cache on the next request, or you can build in some kind of delay.
Im creating a chat app in ASP.NET MVC3.
im using long polling and AsyncController to do so
when a user posts a chat its saved in database , to retrieve should i constantly check database for change in record or after definite interval
or is there an better/ efficient way of doing it
i came across this question but could not get a usable answer.
You may take a look at SignalR for an efficient way. Contrary to the standard polling mechanism (in which you are sending requests at regular intervals to check for changes), SignalR uses a push mechanism in which the server sends notifications to connected clients to notify them about changes.
Since you're already using long polling and an asynccontrolller, why not create a message pool? Take a look at this solution.
In a nutshell, instead of just writing the updated chat to the database, you should also stick it in some sort of queue. Then each user's async thread is listening to that pool waiting for a message to appear. When one appears return the data to the user through your normal operation. When all listening threads have picked up the message it can be removed from the queue. This will prevent you from having several threads hammering your database looking for a new message.
You can give PServiceBus(http://pservicebus.codeplex.com/) a try and here is a sample web chat app(http://74.208.226.12/ChatApp/chat.html) running and does not need database in between to pass message between two web clients. If you want to persist data in the database for logging sake, you can always subscribe to the chat message and log it to database.
I am building a Push notification system, for Android.
I have an ASP.NET web application, hosted on a commercial hosting provider. I have one page that almost always is in an infinite loop waiting for an event to occur.
One host (Android device) loads this page, and remains connected on a persistent connection, till that event occurs. When it occurs, it serves it, and goes back to waiting for it to occur again.
Now, my question is, Is this page being in a perpetual loop, and always connected to a client going to affect the performance of the rest of the web application?
(I think it should not, because servers handle loads of client connections anyway. Am I correct in assuming this?)
Should I deploy this on a different application pool on the server?
Also, is there a better way of doing Push notifications, using persistent connections?
Thanks in advance...
Based on your description, you're going to run into issues. First, having a page that loops forever is going to cause timeout errors (connection timeout defaults to something like 120 seconds). Which, by the way, will cause the app pool to fail/shut down based on how fast it happens (I've accidentally done this, trust me it's not good).
If you don't have to have 100% real time notifications, I'd use a polling setup (let them hit your page once every couple of minutes). If you do have to have 100% real time notifications, and you're targeting 2.2 on up, use Cloud to Device Messaging. Otherwise you're best option will be to create a server application and not going the ASP.Net approach.