Is there such a thing as a Real-time Web Application?

[Charles Law]

What I mean is, I want my web client to be updated in real-time.

The scenario is that I have a database that is updated asynchronously, and
when the update takes place I want to 'notify' my web clients so that they
can display new information. This must be a push rather than a pull, so I
don't want to use a timer on the client.

Is there a way to do this?

TIA

Charles

 

[John Timney \( MVP \)]

You will need to have some form of constant connection between your client
and the web server, typcially an issue in a stateless environment like the
web. You could probably think about using an applet or activex control
connected to a socket server, let the socket server monitor the DB and when
the DB update occurs it can tell its connected clients via your applet that
the update has occured.

 

[Jim Cheshire]

What I mean is, I want my web client to be updated in real-time.

The scenario is that I have a database that is updated asynchronously, and
when the update takes place I want to 'notify' my web clients so that they
can display new information. This must be a push rather than a pull, so I
don't want to use a timer on the client.

Web applications are connectionless. There cannot be a push because
the Web server has no way to push something to a specific client.

What you're asking for would probably be best accomplished using
XMLHTTP. It would be easy enough to return a Boolean indicating
whether or not data have changed. When they have, you could also use
the same method to update only that portion of the page that has
changed.

Jim Cheshire
Blog: http://blogs.msdn.com/jamesche

 

[Cor Ligthert [MVP]]

Charles,

You was a while on the moon.

http://atlas.asp.net/Default.aspx?tabid=47

You should even have seen it from that place.

Cor

 

[Charles Law]

Hi Cor

Thanks for the link. I noticed this when I Googled, but at first-glance it
looked like a third-party tool, and I was looking for a built-in way. Now I
look at it again, it might be just what I am looking for.

Charles

 

[Charles Law]

Hi John

Thanks for the reply. I shall look into this further.

How do the control and socket server test for new data internally? Is it a
poll, or is it more like the way a comm device works?

Charles

 

[bruce barker \(sqlwork.com\)]

note: an atlas solution would be a client polling solution. if you don't
want polling, then as noted above you need to use a java applet or active/x
control to open a socket to you server. you will need to write a new network
service on your server to maintain the connection to the client as asp.net
can not be used for this. one of the open IM server packages would do.


-- bruce (sqlwork.com)

 

[John A. Bailo]

Um, yeah.

Ever hear of Remoting.

It's exactly what he wants.

Check out the Remoting samples, like the chat server/client.

Remoting can update a client when events occur on the server.

And it can all be done in .NET 1.1


There's ajax and atlas, but they require a lot of infrastructure for
something Remoting can do in a few lines of code and some .config entries.

 

[gerry]

but then you aren't talking about the web client anymore but rather a server
side client within the asp.net app

 

[John Timney \( MVP \)]

yes, its usually via some form of poll

 

[John A. Bailo]

Essentially the client has a server "built-into" it. So the server can
message back to it.

You can also remote methods, so that a server can raise an event on the
client that runs a method.

Example, send an alert that a stock market price has changed. The
server raises the remoted event, and the client responds with a change
in the UI.


THis can all be done in 1.1


For 2.0 you can look into what was Indigo, it is now the WCF (Windows
Communication Framework).

There are also some more "webby" type methods, but they seem to require
that the user have IIS running on their workstation.


For myself, I prefer a remoted c# client rather than AJAX, ATLAS or WCF,
or the traditional java applet or application using RMI

It's simple, has a clean implementation, can run using http or tcp.

 

[Charles Law]

Hi Gerry

Thanks, and to all others in this thread. I should say that I use the "web
client" terminology as a phrase of my own invention, and not in any specific
sense of a Web Client. I might have misused the phrase.

I am not meaning to be prescriptive in any way. The aim is to have multiple
client machines able to present information from a central (probably SQL
Server) database, on an intranet (primarily), but generically internet.

I am happy to consider all options, without prejudice. If it is not possible
to construct a push model, I need to adopt something that has a comparable
performance as this is a highly time-sensitive project.

Charles

 

[Charles Law]

Hi John

You can also remote methods, so that a server can raise an event on the
client that runs a method.

Example, send an alert that a stock market price has changed. The server
raises the remoted event, and the client responds with a change in the UI.

That's it. That's precisely it. An example of exactly what I need to
achieve. Can you point me to any examples (ideally), or appropriate keywords
that would yield good hits.

Cheers

Charles

 

[MSDN]

Since this is not a web app then use remoting..

Hi Gerry

Thanks, and to all others in this thread. I should say that I use the "web
client" terminology as a phrase of my own invention, and not in any
specific sense of a Web Client. I might have misused the phrase.

I am not meaning to be prescriptive in any way. The aim is to have
multiple client machines able to present information from a central
(probably SQL Server) database, on an intranet (primarily), but
generically internet.

I am happy to consider all options, without prejudice. If it is not
possible to construct a push model, I need to adopt something that has a
comparable performance as this is a highly time-sensitive project.

Charles

 

[Charles Law]

When I said "all options", I should have added that it will nevertheless be
through a browser. Does that exclude remoting, or can I still use that
technique?

Charles

 

[Charles Law]

Hi John

I have looked for the framework sample, but have not found it yet. I have
found various other remoting samples, but the clients all seem to be Windows
Forms applications, whereas I need the client to be a browser; IE, for
example. Am I missing something?

Charles

 

[gerry]

remoting will not work from the browser unless possibly all of your clients
have the .net framework installed and your page is actually a winform
control - even then you'd have to experiment to see if it would actually
work.

 

[Russell]

Within a browser, ATLAS polling would seem to be his best bet. A JAVA
applet using RMI or just an open socket could respond slightly
faster... but probably only worth it if there are already JAVA
applications on the site. If not, keeping everything in a single
programming language is probably worth the slight inefficiency of using
ATLAS polling.

 

[Randolpho]

Charles,

In general, the "remoting" idea John mentioned is a bad idea with web
applications. You never want a web-page to open a listening socket;
that creates all sorts of security holes, and will likely be denied by
many many firewalls and security settings, anyway. You're guaranteeing
yourself a ton of complaints and headaches.

You cannot achieve "realtime" in a real web application, the web just
wasn't designed for "push" content.
AT BEST, you can fake it with frameworks like Atlas that will check for
updates periodically.

Plus, you're not thinking about scale. Push content simply doesn't
scale well. If you want to automatically push content to connected
users, you need to maintain a list of who's connected and who's not. If
you use listening sockets (John's "remoting" idea), you need to
maintain IP addresses for each of those clients on your server. What if
one of them closes the program? Yeah, TCP timeout, slowdowns, then you
have to remove the IP address, but what if it's just a short-term
network outage? Your client won't like being disconnected, and how do
you know whether or not to try to connect again? If you're going to do
push content, you have to maintain permanent TCP connections to your
client, but that will bog down your server after only a few hundred
connections, so you'll have to look into server farming, and that
involves making sure each server in the farm gets updated...

It gets more and more complex the more you think about the architecture
of the system, and I haven't even addressed security. Add that to the
mix, and you're looking at Excedrin Headache number 127.0.0.1 (it just
keeps looping back at ya!).

My suggestion: either forget about doing actual push content, or fake
it with Atlas.

 

[Randolpho]

I am not meaning to be prescriptive in any way. The aim is to have multiple

client machines able to present information from a central (probably SQL
Server) database, on an intranet (primarily), but generically internet.

Hmm, I missed that post. Ok, if this isn't really a web application,
but a rich-client/server application (preferrably written in
Windows.Forms), then you're in luck, and you can forget what I just
wrote.

SQL Server 2005 has a new feature called Query Notification; the server
will notify the client when the results of a query have changed. You
can use this for your "realtime update" requirement. I don't know a
whole lot about it, but I believe you still have to maintain a
dedicated connection from the client to the server. However, if you're
not doing a web application odds are you're not going to be as worried
about scale as I was in my previous post.

The link below will help, or you can google for SQL Server 2005 "Query
Notification".

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/querynotification.asp