Phantasmal Site > DGD > Writing a Library > HTTPD

Writing an HTTPD in DGD

If you write an HTTPD that can read files in your MUD (as opposed to one that presents an entirely different file model, something it makes up), remember not to let people randomly get code out of your MUD directories. Be sure to only send out the files you intend people to get. Be careful to normalize filenames first (remove leading '..' paths, et cetera) so that nobody can fool you by using a different path format. This helps to keep your HTTPD from causing security problems in your MUD.

You can also allow players to play over HTTP, or some related protocol. If so, please remember not to identify your players by IP address. Issues like firewalls and NAT can greatly confuse your MUD server, causing multiple players to be treated as one, or a player to suddenly lose connection when he appears to change IP addresses. Cookies are one of several more reliable tracking methods, though there are certainly others.

Bear in mind that standard HTTP does not allow 'push' code for things like 'tell' and 'say', nor for sudden events like a creature entering a room and attacking. For that reason, Java (or Javascript?) or some more proprietary replacement like ActiveX may be necessary to allow your MUD proper two-way interactivity.

More complex setups can work quite well, of course. Christopher Allen describes the Skotos setup like this:

You might want to take a look at a couple of Skotos games, in particular, Castle Marrach and Grendel's Revenge. Both have gifs and jpegs under client control.

Our basic technique is to have a pane for flowing text that is imbedded inside an html page. This text pane can receive special commands that it will send out to the DOM of the web page it sits inside. This allows us to change the whole web page dynamically. We have three clients that use this technique, an Active-X client that is based on Pueblo, a Java client, and a Mozilla Javascript client.

The RFC for HTTP 1.0 is here. It may be useful for your implementation efforts.

To set cookies, you may find Javascript is useful. The following script was obtained by Wes Connell off a Javascript help page:

<script language="JavaScript">
<!--

⁄⁄ Use this function to retrieve a cookie.
function getCookie(name){
var cname = name + "=";
var dc = document.cookie;
    if (dc.length > 0) {
    begin = dc.indexOf(cname);
        if (begin != -1) {
        begin += cname.length;
        end = dc.indexOf(";", begin);
            if (end == -1) end = dc.length;
            return unescape(dc.substring(begin, end));
        }
    }
return null;
}

⁄⁄ Use this function to save a cookie.
function setCookie(name, value) {
document.cookie = name + "=" + escape(value) + "; path=⁄";
}

⁄⁄ Use this function to delete a cookie.
function delCookie(name) {
document.cookie = name + "=; expires=Thu, 01-Jan-70 00:00:01 GMT" +  "; path=⁄";
}
⁄⁄-->
<⁄script>
  

Using the above, the following code can be included:

send_html_output("<script language="JavaScript">);
send_html_output("setCookie(\"ACCOUNTNAME\", account_name);");
send_html_output("setCookie(\"PASSWORD\", encrypted_password);");
send_html_output("<⁄script>");
  

From: Bart van Leeuwen
Subject: [DGD] DGD http daemon?
Date: Tue Feb  8 20:58:01 2005

Hey,

Last week I rewrote a small http serving object from my mud into a
relatively complete http server.

You can see it in action by pointing your browser at http://mud.wotf.org/

Currently the code is somewhat specific to my kernel (and modified driver)
but if people are interested in this and someone is willing to help test
it for a generic DGD kernel then I can make the code available
(for non commercial use only however)

A somewhat preliminary README can be found at
http://mud.wotf.org/httpd.html, which provides some info on what it
supports and how it works.

Bart.

ps. in the next 1 1/2 weeks I'll be rather busy and away from home, I will
read my mail, but I won't be able to finish the cleaning up of the code. I do want to get an
idea on if I should put in the efford to remove dependencies on my own
kernel however.

From: Joakim Romland
Subject: Re: [DGD] DGD http daemon?
Date: Wed Feb  9 00:30:01 2005

On Tue, 8 Feb 2005 15:26:53 -0500 (EST), Stephen Schmidt wrote:
> There are all kinds of design-related problems with using
> a primarily http interface for playing the game; those
> don't interest me so much. The question is really whether
> this daemon could be the basis for code support for such
> a design. If it is, then having a version for a general
> DGD kernel (or even a specific kernel that could be
> released as a package with the daemon) would be extremely
> useful.
>
I tinkered (and still touch it when I get some inspiration) with a
httpd that is built on top of the Kernel Library. It's somewhat more
bloated and should really be divided into several sub-projects. I
wrote it mostly to create a WebDAV daemon -- but I needed a httpd for
that (see SVN repository at
http://developer.berlios.de/projects/dgd-httpd/)

Either way, you can do some trickery with the xmlHttp object that is
available in most browsers these days. But as always with HTTP, you
need to do polling to get new state. Although, if you have support for
keep-alive sessions in your httpd you poll through the same connection
all the time (if you poll more often than the timeout is set to that
is).

I tested this using xmlHttp some time back using the above httpd to
write a web-chat... And sure, you get a delay of a couple of seconds
(depending on how often you poll), but to the user (browser) it is
completely invisible; eg. new information just pops up. You can poll
quite a few times per second if you want to too, but HTTP headers give
you a quite a bit of overhead. :-)

It is limited in its usefulness, but I can imagine the creative person
can come up with some nifty stuff.

If you have no idea what I am talking about, then I have relevant
snippet of the client code here (if you want the backend as well, just
drop me a mail -- it's not much code):

[ snip ]
    function createXmlHttp() {
        /* Only support for Mozilla atm. */
        return new XMLHttpRequest();
    }

    function result() {
        if(xmlHttp.readyState == 4 && xmlHttp.responseText) {
            currentBuff.innerHTML = xmlHttp.responseText;
        }
    }

    function fetch() {
        if(xmlHttp && xmlHttp.readyState != 0) {
            xmlHttp.abort();
        }

        if(xmlHttp = createXmlHttp()) {
            xmlHttp.open("GET", urlServer + urlGetPath + "?since=1", true);
            xmlHttp.onreadystatechange = result;
        } else {
            DEBUG("Failed to create xmlHttp");
        }

        xmlHttp.send(null);
    }

    function send(msg) {
        if(xmlHttp && xmlHttp.readyState != 0) {
            xmlHttp.abort();
        }

        if(xmlHttp = createXmlHttp()) {
            xmlHttp.open("GET", urlServer + urlSendPath + "?since=1&message=" +
msg, true);
            xmlHttp.onreadystatechange = result;
        } else {
            DEBUG("Failed to create xmlHttp");
        }

        xmlHttp.send(null);
    }

    function main() {
        fetch();
        setTimeout("main()", refreshRate);
    }

[ /snip ]


// Joakim

From: Bart van Leeuwen
Subject: Re: [DGD] DGD http daemon?
Date: Wed Feb  9 00:43:01 2005

On Tue, 8 Feb 2005, [ISO-8859-1] Petter Nyström wrote:

> If you are releasing the code, I'd be interested in using it. I am not
> running Dworkin's kernel lib though, so I can't really help you getting a
> generic version of the code. I am just a fellow lib coder who have often
> thought it'd be nice to have an internal web server for the simpler
> purposes that have been mentioned, but I have never given the project
> priority. With your code, I can't believe there would be that much work to
> integrate it into my mudlib.

If you know how your kernel's user/connection handling is working then
you should have little trouble getting this to work on your kernel.

>
> If you put the code in public domain, let us know!

It will be available for non-commercial use once I cleaned it up a bit and
have a little bit more documentation for interfacing with it (which should
take some 2 weeks due to me being away from home for a while)

As a sidenote, there is also a project at
http://developer.berlios.de/projects/dgd-httpd/ which provides a (for what
I can tell more heavyweight) http server for DGD. If you need things like
XML parsing or webdav, take a look at that as well. What I have written is
extremely minimalistic in comparison.

Bart.