Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / October 2005

Tip: Looking for answers? Try searching our database.

Push Alert to Browser

Thread view: 
Enable EMail Alerts  Start New Thread
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

Rate this thread:







Free Magazines

Get 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 ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.