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.