Push Alert to Browser

[Nick K.]

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]

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

 

[Jason Bailey]

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.

 

[Steve C. Orr [MVP, MCSD]]

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.

 

[Lucas Tam]

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.

 

[Nick K.]

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.

 

[bruce barker]

this is available in net 1.0, it just javascript doing a postback.

-- bruce (sqlwork.com)

 

[Mickey Williams [C# MVP]]

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 [C# MVP]]

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]

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.

 

[Nick K.]

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]]

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.

 

[Jason Bailey]

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.

 

[Guest]

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

 

[Guest]

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