| Groups | Blog | Home |
asp.net webservices : Push Alert to Browser
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?
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. -- I hope this helps, Steve C. Orr, MCSD, MVP http://Steve.Orr.net [quoted text, click to view] "Nick K." <nick@bogus.com> wrote in message news:eivyTNnpEHA.3252@TK2MSFTNGP14.phx.gbl... >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? > > >
this is available in net 1.0, it just javascript doing a postback.
-- bruce (sqlwork.com) [quoted text, click to view] "Lucas Tam" <REMOVEnntp@rogers.com> wrote in message news:Xns9573C7DF057BAnntprogerscom@140.99.99.130... > "Nick K." <nick@bogus.com> wrote in > news:eivyTNnpEHA.3252@TK2MSFTNGP14.phx.gbl: > > > 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. > > -- > Lucas Tam (REMOVEnntp@rogers.com) > Please delete "REMOVE" from the e-mail address when replying. > http://members.ebay.com/aboutme/coolspot18/
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> -- Mickey Williams Author, "Visual C# .NET Core Ref", MS Press www.neudesic.com www.servergeek.com [quoted text, click to view] "Nick K." <nick@bogus.com> wrote in message news:eivyTNnpEHA.3252@TK2MSFTNGP14.phx.gbl... > 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? > > >
[quoted text, click to view] "bruce barker" <nospam_brubar@safeco.com> wrote in message news:ex3jmVopEHA.376@TK2MSFTNGP14.phx.gbl... > 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.
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 [quoted text, click to view] "Nick K." <nick@bogus.com> wrote in message news:eivyTNnpEHA.3252@TK2MSFTNGP14.phx.gbl... >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? > > >
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. [quoted text, click to view] "Jason Bailey" <jasonbailey2000@hotmail.com> wrote in message news:415B45FB.7060806@hotmail.com... > 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. > > Nick K. wrote: > > 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? > > > > > >
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. [quoted text, click to view] Nick K. wrote:
> 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? > >
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! "Mickey Williams [C# MVP]" <my first name at servergeek dot com> wrote in message news:uAdfWXopEHA.3688@TK2MSFTNGP09.phx.gbl... [quoted text, click to view] > 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> > > > -- > Mickey Williams > Author, "Visual C# .NET Core Ref", MS Press > www.neudesic.com > www.servergeek.com > > > > "Nick K." <nick@bogus.com> wrote in message > news:eivyTNnpEHA.3252@TK2MSFTNGP14.phx.gbl... > > 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? > > > > > > > >
[quoted text, click to view]
>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-ass 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. -- Mickey Williams Author, "Visual C# .NET Core Ref", MS Press www.neudesic.com www.servergeek.com
"Nick K." <nick@bogus.com> wrote in
news:eivyTNnpEHA.3252@TK2MSFTNGP14.phx.gbl: [quoted text, click to view] > 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. -- Lucas Tam (REMOVEnntp@rogers.com) Please delete "REMOVE" from the e-mail address when replying.
"bruce barker" <nospam_brubar@safeco.com> wrote in news:ex3jmVopEHA.376
@TK2MSFTNGP14.phx.gbl: [quoted text, click to view] > 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. -- Lucas Tam (REMOVEnntp@rogers.com) Please delete "REMOVE" from the e-mail address when replying.
See below...
[quoted text, click to view] Nick K. wrote: Custom C# Windows Service on Windows 2003 Server > I am interested and have a few questions: > > Your messaging server, is this a custom piece of code or a Microsoft > product? [quoted text, click to view] > The coding was done through researching many different sites and , > 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? 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. [quoted text, click to view] >
> > > I am impressed with what you have done, especially since others say, "don't > try" or "it can't be done". Congratulations. > > > "Jason Bailey" <jasonbailey2000@hotmail.com> wrote in message > news:415B45FB.7060806@hotmail.com... > >>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. >> >>Nick K. wrote: >> >>>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? >>> >>> >>> > >
Don't see what you're looking for? Try a search.
|
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |