.NET Forum / ASP.NET / Web Services / October 2005
Push Alert to Browser
|
|
Thread rating:  |
Nick K. - 29 Sep 2004 23:28 GMT I am looking for architecture to push information from a server to a client browser. This information would be in the form of an alert. What I do not want to do is have the browser be on a timer and update every few seconds. What options do I have to put into place such a feature?
Mark Fitzpatrick - 30 Sep 2004 00:01 GMT Your best, and probably easiest bet, is to avoid using push technology entirely since it's too much of a pain to work with and died not long after coming out of the box. The simplest thing I can think of is to just set a meta tag for the page to refresh the page automatically. This is nice because it doesn't involve any programming. The downside is it does refresh the entire page. You could then create an inline frame that would present a much smaller area of the page, and in this area have a web page called that refreshes every so often. This should work, though I haven't toyed with an embedded refresh like this in an iframe before.
When setting how often to refresh keep performance in mind. If you have a number of browser windows open from different users then you'll start to get a lot of constant hits checking for an alert status. This could drop the performance down but you should be able to minimize it by doing some very careful programming.
Hope this helps, Mark Fitzpatrick Microsoft MVP - FrontPage
>I am looking for architecture to push information from a server to a client > browser. This information would be in the form of an alert. What I do not > want to do is have the browser be on a timer and update every few seconds. > What options do I have to put into place such a feature? Jason Bailey - 30 Sep 2004 00:32 GMT I have implemented this architecture in an enterprise application for a mortgage company. We used a "Messaging" paradigm where there was a .NET assembly loaded in a hidden IFRAME in a webpage that was invoked on the client. On successful login, this assembly registered with a server-side Windows Service that placed the client IP in a hashtable. Every two minutes, the server "pinged" the client IPs in memory with a two byte challenge to ensure they were still alive (i.e., the client didn't close the browser or navigate to another site). If the server did not receive a response, it removed that IP from its hashtable.
When a message needed to be pushed to the client, the server received a .NET remoting call from our server-side app to push the message to a particular user. The messaging server did a quick lookup in its hashtable for a registered client IP that matched the unique login key that was passed in through the remoting call. If it found the login key, the messaging server would push the message to the client over TCP/IP port 80 and the client assembly would pass the message to the browser and dynamically update an HTML table on the page with the new message. In your case, you could have IE pop up a messagebox or you could create a custom Windows.NET form to show the message directly from the embedded .NET assembly.
This has been in production for over a year with no problems and works reliably.
Hope this helps.
> I am looking for architecture to push information from a server to a client > browser. This information would be in the form of an alert. What I do not > want to do is have the browser be on a timer and update every few seconds. > What options do I have to put into place such a feature? Nick K. - 30 Sep 2004 01:07 GMT I am interested and have a few questions:
Your messaging server, is this a custom piece of code or a Microsoft product?
The client assembly that receives the message, is this a custom piece of code or a Microsoft product?
How exactly, does this client assembly pass the message to the browser?
Do you have a link to code that would explain any of this more, especially the .Net assembly in the IFRAME or an assembly communicating with the browser?
I am impressed with what you have done, especially since others say, "don't try" or "it can't be done". Congratulations.
> I have implemented this architecture in an enterprise application for a > mortgage company. We used a "Messaging" paradigm where there was a .NET [quoted text clipped - 27 lines] > > want to do is have the browser be on a timer and update every few seconds. > > What options do I have to put into place such a feature? Jason Bailey - 01 Oct 2004 01:29 GMT See below...
> I am interested and have a few questions: > > Your messaging server, is this a custom piece of code or a Microsoft > product? Custom C# Windows Service on Windows 2003 Server
> The client assembly that receives the message, is this a custom piece of > code or a Microsoft product? Custom C# Class
> How exactly, does this client assembly pass the message to the browser? > > Do you have a link to code that would explain any of this more, especially > the .Net assembly in the IFRAME or an assembly communicating with the > browser? The coding was done through researching many different sites and , together, building the solution that I've outlined. There's not any one site that gives you everything. Most of what we needed to build the plumbing was found on MSDN.
> I am impressed with what you have done, especially since others say, "don't > try" or "it can't be done". Congratulations. [quoted text clipped - 39 lines] > >>>What options do I have to put into place such a feature? edwilson - 29 Oct 2004 16:28 GMT There's a catch to this though. You have to have the .NET framework installed on the clients as well as the server. Otherwise the client-side assembly won't work.
I've been trying to come up with a good solution to this myself. It's interesting that this can be done in Java (servlets, JavaScript, & DHTML see http://www.pushlets.com) pretty easy, but it seems to be a real chore in .NET.
Eric
> I have implemented this architecture in an enterprise application for a > mortgage company. We used a "Messaging" paradigm where there was a .NET [quoted text clipped - 27 lines] > > want to do is have the browser be on a timer and update every few seconds. > > What options do I have to put into place such a feature? Steve C. Orr [MVP, MCSD] - 30 Sep 2004 00:35 GMT You cannot push to a browser. Browsers do not support this capability. The only way it could be done is to embed a lower level component in your page, such as an ActiveX control. Then you'd have to write all the networking code manually.
It is far more feasible to have the browser initiate communication on a timed interval even if it's not ideal.
 Signature I hope this helps, Steve C. Orr, MCSD, MVP http://Steve.Orr.net
>I am looking for architecture to push information from a server to a client > browser. This information would be in the form of an alert. What I do not > want to do is have the browser be on a timer and update every few seconds. > What options do I have to put into place such a feature? Lucas Tam - 30 Sep 2004 00:38 GMT > I am looking for architecture to push information from a server to a > client browser. This information would be in the form of an alert. > What I do not want to do is have the browser be on a timer and update > every few seconds. What options do I have to put into place such a > feature? If you have ASP.NET 2.0 Beta, you can try doing ClientCallBacks.
 Signature Lucas Tam (REMOVEnntp@rogers.com) Please delete "REMOVE" from the e-mail address when replying. http://members.ebay.com/aboutme/coolspot18/
bruce barker - 30 Sep 2004 01:35 GMT this is available in net 1.0, it just javascript doing a postback.
-- bruce (sqlwork.com)
> > I am looking for architecture to push information from a server to a > > client browser. This information would be in the form of an alert. [quoted text clipped - 3 lines] > > If you have ASP.NET 2.0 Beta, you can try doing ClientCallBacks. Mickey Williams [C# MVP] - 30 Sep 2004 01:40 GMT > this is available in net 1.0, it just javascript doing a postback. > > -- bruce (sqlwork.com) You don't need a postback, you just need to use XMLHTTP from javascript.
Lucas Tam - 30 Sep 2004 02:26 GMT "bruce barker" <nospam_brubar@safeco.com> wrote in news:ex3jmVopEHA.376 @TK2MSFTNGP14.phx.gbl:
> this is available in net 1.0, it just javascript doing a postback. ASP.NET 2.0's Client Callback is much more than a postback. Actually you're not postingback a page at all.
Rather, ASP.NET can dynamically update a webpage using the XMLHTTP object. Most of the update logic is encapsulated in VB.NET so you don't need to mess with Javascript + XMLHTTP.
You can emulate ASP.NET 2.0's Callback feature by calling the XMLHTTP object via Javascript manually... of course without .NET 2.0, it's a bit ugly to do.
 Signature Lucas Tam (REMOVEnntp@rogers.com) Please delete "REMOVE" from the e-mail address when replying. http://members.ebay.com/aboutme/coolspot18/
Mickey Williams [C# MVP] - 30 Sep 2004 01:39 GMT 1) Push script commands down to an iframe via a persistent connection, more or less like the well-known command pattern. Difficult, requiring good kung-fu skills, but not impossible.
2) Use client-side jscript and XMLHTTP to download an XML document asynchronously from the server. This is an IE 5.0 or later-only solution, but Mozilla has a similar interface. I have an example below.
3) Wait for ASP.NET 2.0, which wraps #2 in an easier-to-use programming model.
Here's the HTML+script example for #2 -- I put a simple XML doc up on servergeek so you can test it.
<html> <script> var req = null; function onUpdate() { req = new ActiveXObject("Msxml2.XMLHTTP.3.0"); req.open("GET", "http://www.servergeek.com/foo.xml", true); req.onreadystatechange= HandleStateChange; req.send(); }
function HandleStateChange() { if (req.readyState == 4) { alert(req.responseXML.xml); setTimeout('onUpdate()', 1000); } }
</script> <body onload="setTimeout('onUpdate()', 1000)"> <div id="target">X</div> </body> </html>
 Signature Mickey Williams Author, "Visual C# .NET Core Ref", MS Press www.neudesic.com www.servergeek.com
> I am looking for architecture to push information from a server to a client > browser. This information would be in the form of an alert. What I do not > want to do is have the browser be on a timer and update every few seconds. > What options do I have to put into place such a feature? Nick K. - 30 Sep 2004 02:27 GMT I am familiar with using Msxml2.XMLHTTP.on the client side. I have used such javascript to call a web service. But that's not really pushing a message to the client is it? If you have hundreds of users calling a web service every few seconds, that's a lot of network traffic!
> 1) Push script commands down to an iframe via a persistent connection, more > or less like the well-known command pattern. Difficult, requiring good [quoted text clipped - 41 lines] > > want to do is have the browser be on a timer and update every few seconds. > > What options do I have to put into place such a feature? Mickey Williams [C# MVP] - 30 Sep 2004 05:04 GMT >If you have hundreds of users calling a web service every few seconds, that's a lot of network traffic!
A lot? How much is a lot? It depends. The best solution depends on many things, including the number of users you need to support, the network topology, the server hardware you're using, the failure modes you prefer, and the code complexity you're prepared to deal with.
Look - you essentially have two families of options, neither of them especially scalable. I outlined both. I've used both. Each of them could be called a better solution for specific situations. You need to have someone with architectural skills evaluate the options. There's no need to be a smart-a.s when people try to help.
If the client can specify exactly what it wants, it's generally better to have the client request the data, especially when combined with an effective caching strategy. Even a commodity server can handle hundreds of users calling back for small XML fragments if you know what you're doing.
OTOH, if the server is the only party that can determine when/what needs to be updated, you can go the persistent connection route, but it's non-trivial to implement, and it's not exactly a scalability winner either - state and cache management can be difficult to handle. Can you handle the case where a client misses an update? Does the client watchdog the server? What happens if the watchdog expires? How do you resynchronize when required? If you're serving from a farm, what happens when you lose a farm element? How do you serve fairly in a farm -- or do you tolerate imbalances? There are a large number of edge cases that complicate a real push implementation.
 Signature Mickey Williams Author, "Visual C# .NET Core Ref", MS Press www.neudesic.com www.servergeek.com
Ric - 07 Oct 2005 20:21 GMT Technically, you can not 'really' push from the server. However, if someone browses to a site you own, you can do a managed pull. On IE (with xmlHttp), you have to poll the server, which can consume alot of resources. Howver, on Mozzilla, you can do ONE request, and let the server respond as events happen with no time out and without polling the server. Note: IE can do something similar with IFRAMES (yuck!) or Remote Scripting (Insecure).
See my other posts to see an example
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|