I’ve been looking around some say I need to make a pooling timer solution of sorts. in a ajax enviroment. it sounds good but I don’t want to make a new request every 1-5 seconds, just to be sure to have the latest updated data on the page.
so I’ve heard something about signalR, but it sounds overly complicated to implement, I guess mostly cause it’s unknown teritory for me.
I’ve also read something about silverlight being able to help to this endevor.
Case is simple I got a chart populated with database values, now this database some days change every second, other times it wont hold any new data for hours. I want to be able to just display current live Data.
I’m using MVC 3 with Razor engine, mssql database, and a IIS express 7.5.
my options outside of this enviroment is very limited.
it’s going to be used internally in this company only. there will be between 10-50 places accessing the page.
my concern is not to overload the company servers and network with unnessesary load.
Thanks in advance for any answers.
I want a discussion of technoligies and I wish to find the least invasive and fast/easiest development time on this solution .
As you have determined, you can periodically poll using AJAX to see if you need to refresh. If that doesn’t sound good, you could try a COMET approach, which involves opening a request that both the client and server keep open, until the server has a message. At that time, it would send a message with whatever instructions you wish (like reload this page) and end the connection, where the client script would then do something with that message. A practical example of that is how Facebook handles notifications. The net result is your server experiences less traffic, and users experience a magical “instant” response at the client. On the other hand, this approach requires proper construction and tuning on the server and in your application, as keeping lots of connections open can create problems.
There are some ASP.NET modules for implementing a COMET solution (and Signalr sounds like one of such solutions), but I wonder why the polling option is so bad if you’re only using it on the intranet. You don’t necessarily have to poll in several independent areas in your client; you could have one notifier (this is all in JS, mind you) which takes subscriptions from other components, who submit specifics on what things they want you to check on. Then poll once over AJAX to some MVC action with a message containing all relevant subscriptions. I don’t imagine that being a big network buster, as I have an application that does that on a pretty fairly large scale.
On the server side, your action would parse that message into jobs, check on each one as requested, and send a response message, if there’s anything to do. Then your client notifier receives the message and sends the results to any subscribers if there’s anything to do (a trivial example: refresh the page, or more appropriately, refresh a section of the page that has changes… you can use JavaScript- preferably through jQuery- to replace the contents of an element with HTML retrieved from your MVC action to change the contents).
It may sound complicated, but it’s not really, particularly in comparison to managing a COMET solution, and you can do it with off-the-shelf technology.
The Silverlight technique you mentioned sounds like using a WCF duplex service contract using a dual HTTP binding, which would allow the server to initiate requests to the client. It’s certainly an option, as you could have a Silverlight notifier app, similar to what I mentioned earlier, sitting in your page, taking in subscribers, and receiving push messages from the server. I’ve not had a chance to implement a duplex service in an actual application, so I don’t know how practical it is in a production environment.