Playing around with creating a web-based MUD. The problem I'm running into is dealing with sudden events that occur in the game (Another player comes into the room, you are suddenly attacked by a monster, etc).

Due to the way HTTP is a connectionless protocol, there isn't any graceful way (that I am aware of) to update information on the browser screen once the data is 'written' to the browser. The only approach I've been able to come up with is an ugly brute force method where a small or hidden frame refreshes every second to get information from a server-based message dispatcher. This beats the hell of the web server and seems a lame way to accomplish this.

Anyone know of a better way?

This might be what you're looking for.

http://www.wsbtv.com/weather/?z=nav

Click on the 'Early Warning Doppler 2' image and you can see the countdown work.

view the source code to see the javascript.

That example seems to rely on the method I am trying to avoid - having the page refresh itself every X seconds. It works great for a weather image that is only refreshed every 180 seconds, but I dont see anything that would support updating the info inbetween refreshes, such as a sudden tornado warning or something.

In the scenario I'm trying to code, I'd have to refresh the screen every second to check for new info, and I'm trying to avoid something that is going to thrash the server so hard. 100 users refreshing every second is going to beat the crap of of the server and drink large amounts of bandwidth with all the HTTP overhead.

Perhaps there is no other way with the HTTP protocol. I realize that what I am asking is outside the normal functionality of HTTP. I would need something more along the lines of a connection oriented protocol like Telnet, where the server can send new information any time that it needs to. With HTTP, the server has to wait around for the user to make another request before it can get any more info out to the user.

Am curious if anyone has coded around such a thing before, perhaps a javascript piece that listens to a socket on the same IP as the webserver, that could somehow change state from 0 to 1 which could then trigger the page to refresh if something important occured. Hopefully something easier than that. Maybe some interesting use of the HTTP KeepAlive functionality, but I've never seen any two-way communication over a KeepAlive connection, everything I've seen is simply to eliminate the overhead of opening a port 80 socket connection with each request. But maybe there is a way for a server to send back a "hey, look at this" type message over the KeepAlive. But nothing I know of.

Any ideas?

Sorry, I have no ideas, but I am very interested in this subject. So, I will be checking back to see if anyone has any solutions.

I have seen the hidden-iFrame approach, but it does require that the iFrame's form repost to the server at a regular interval.

-Van

The best method I've come accross is to use a hidden iFrame or Frame. This refreshes regularly and uses javascript to write to the main page. The way I'd do it is to send the last refresh date with each new request, which then sends back a page that contains:
- last refesh date (for the next refresh)
- list of events that have occurred since that refresh date.

The other option is to move client side with Java, ActiveX Control or a full client side app.

regards
David Cameron

I agree with David, because the solution you are asking for Klom, is much the same as a chat system which also requires frequently updates.

So yes, go and see if there might be an Java applet or ActiveX component available for your needs.

Btw. coding a MUD yourself? oh that brings me memories of text based apple consoles at many educational institutions. I wonder, isn't there any of these system available for download already?
Well, just a thought. Have fun, and do let us know if you find a solution. :)


Regards
Carsten Berggreen

Monolith-Systems
Denmark

HTTP is indeed connectionless. If you are looking for platform independance, you're going to need something like a Java Applet that can maintain a persistant connection to the server.

Cheers
Ken

I take it the Java Applet opens a socket to the server. Don't you then also need a listening socket on the server? Is there some neat way of avoiding having to write a stack of sockets code and potentially doing a bad job of it, opening security holes?

regards
David Cameron