I'm looking for a mechanism in which the server (ASP.Net app) can send notifications to the client controls to refresh themselves. For instance a browser might be display a datagrid. Rather than polling the server, the datagrid remains static until some event on the server triggers a notification to be sent to the client control to refresh itself.
Do the telerik controls provide a solution for this situation? I'm no ajax expert, but I'm wondering if an ajaxified control can listen and respond to server notifications, sort of like a long running callback.
11 Answers, 1 is accepted
I don't believe communication triggered by the server-side can be achieved in the web world -- you can still achieve the desired effect via an ajaxified timer control (either Telerik's, or the ASP.NET AJAX one for example) but of course the communication would be triggered by the client-side and the server would respond to the requests accordingly.
I was thinking about this some more as I read about the Ajaxmanager and the timer controls. There are definite holes in my ajax knowledge, but what's the possibility of a process like this could work?
- A hidden control on the dashboard page initiates a callback to a webservice with userid parameter. The webservice adds the callback sessionid to a correlation table along with the passed in userid, then leaves the callback session open. This hidden ajaxified control would block, but shouldn't affect the rest of the page.
- Meanwhile some server-side process (db trigger, etc) recognizes when data has changed requiring the client to be refreshed. In that case it checks the correlation table to identify the currently open callback sessionid associated with the userid, then returns a refresh notification to the hidden control, still blocking waiting for a response.
- The hidden control receives the server's response, then causes the appropriate page controls to refresh.
- Finally the hidden control starts the process again by calling back into the webservice.
I'm making these assumptions:
- A callback session can be identified with an id (or some other way)
- A webservice in the same domain can come along and randomly communicate with an open callback session if it knows the it's id
- A callback session wont timeout after blocking for an indefinite period
- The webservice being called into wont itself block. I could see lots of blocking webservice instances choking the server.
- The complexity and any performance hits wont be a greater load than simply polling the the timer. My goal is to prevent unnecessary polling when nothing has changed server side.
Thanks for your thoughts
If you just need to keep the session alive, any standard Ajax call should do this since it does a complete postback on the server. As such, if you have an Ajax call triggered by a timer, the session will stay alive.
If you need a push server, you might consider a solution like lightstreamer
Their website explains the technology and provide some white papers ...
I'm looking for a similar solution. It's been almost 2 years from the last post in this thread, I'm wondering if Telerik has added such feature or solution to this problem?
Have you considered using an asp Timer in combination with our ajax manager or panel for the purpose discussed in this forum thread? We have a couple of live demos which illustrate how this can be done:
the Telerik team
The samples you mentionned are still "pull" model since the refresh is being trigerred by the client and not the server.
For anyone else following this thread, I've actually found a .Net comet server which seems to be answering this need, it is called WebSync (http://www.frozenmountain.com/websync/)
I'm actually suprised that Telerik is not aware of them as they specifically say on their web page that they integrate with Telerik!
Seems promissing, will give it a try.
Thank you for letting us know about this solution which uses reversed Ajax technology and initiates refreshes which are triggered on the server. Feel free to use this method and let us know about the result when integrated with our AJAX components.
the Telerik team
I've got a live chat system that relies on frequent "pings" back to the server, which I wish I wish I didn't have to do so often. They're as light-weight as possible, but they still have to come in very frequently in order for the chat to remain live.
Thanks for posting this.
Has anyone had any success with this approach?