I'm having a heck of a time trying to get this to run

[Ragnar]

For the best shot at it I created a clean Redhat VM, installed httpd, php & php-cli then put the uncompressed folder into /var/www/html, started up httpd and pointed the local browser at the index.php in the vm_client folder to reach the main window.
When I run "php -q server.php" it starts with binding the 127.0.0.1:12346 port and the 837 ports but then spams and spams about offsets.  I found the various spots in /includes/classes/Server/SocketServer.class.inc to edit so that its not always directly references undefined array members so that's delt with.  I'm still left with a situation where I can see attempts to connect to the server result in "Client 0 connected", "Good handshake for client [0]" but then "Disconnecting 0:  bad read." and in the browser window it just shows "WebSocket Error:".

So I know the client is able to make contact with the server process but something fails right away and I haven't a clue how to trouble shoot this, if I telnet to the 12346 it will just sit there with a "Client 0 connected" mentioned in the server's output.  Any help here?

[John DeLancey]

Unfortunately, for the moment, the websocket mechanisms in the PHudBase sever code are badly out of date.  The specs have changed many times over and, while I feel confident I can get it up to speed, I am unfortunately entirely unable to spend any time on it at the moment (have to pay the bills...).

I'm very sorry for the inconvenience.  I hope you'll give it another try when I'm able to update it in the future.  Thank you!

- John

[Ragnar]

Ahh thank you for the incredible fast response, I suppose if I wanted to find a way to use an older set of libraries that might work?  Do you know what your demo link's running on, it definitely still works so there has to be a way.  :)    I'd be willing to have a whole older distro VM running just to get at this potentially awesome ability for my mud :) 

[John DeLancey]

It's actually a problem with how web browsers (Chrome, Firefox, and Safari) handle WebSockets.  There is, unfortunately, little to no chance of making it work without significant change to the server code for PHudBase. :(

I'll try to get back on it as soon as I possible can.  Thanks!

[Michael Elford]

I'm working my way through this, the first error causing the disconnection has to do with the initial handshake:

I've modified the file wm_server/includes/classes/Server/WebSocketHandshake.class.inc (constructor)

    public function __construct($buffer) {

        $resource = $host = $upgrade = $connection = $origin = $key = $protocol = $version = $code = $handshake = null;

        preg_match('#GET (.*?) HTTP#', $buffer, $match) && $resource = $match[1];

        preg_match("#Host: (.*?)\r\n#", $buffer, $match) && $host = $match[1];

        preg_match("#Upgrade: (.*?)\r\n#", $buffer, $match) && $upgrade = $match[1];

        preg_match("#Connection: (.*?)\r\n#", $buffer, $match) && $connection = $match[1];

        preg_match("#Sec-WebSocket-Key: (.*?)\r\n#", $buffer, $match) && $key = $match[1];

        preg_match("#Sec_Websocket_Origin: (.*?)\r\n#", $buffer, $match) && $origin = $match[1];

        preg_match("#Sec_WebSocket_Protocol: (.*?)\r\n#", $buffer, $match) && $protocol = $match[1];

        preg_match("#Sec_WebSocket_Version: (.*?)\r\n#", $buffer, $match) && $version = $match[1];

        $GUID                   = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";

        $ConcatKey              = $key.$GUID;

        $SHA1                   = sha1($ConcatKey,TRUE);

        $accept                 = base64_encode($SHA1);

        $this->__value__ =

               "HTTP/1.1 101 Switching Protocols\r\n"                           .

               "Upgrade: WebSocket\r\n"                                         .

               "Connection: Upgrade\r\n"                                        .

               "Sec-WebSocket-Accept: {$accept}\r\n"            ;

    }

This removes the handshake error that Chrome is reporting, still hasn't fixed all the problems (isn't changing "PhudBase Connection" to connected in the client and getting a DOM exception 11 error when I attempt to connect).  Will post updates if/when I get somewhere.  

[Michael Elford]

Blargh, change the last line to be:

               "Sec-WebSocket-Accept: {$accept}\r\n\r\n"                ;

Now getting connected ok.  Wont let me connect to muds...Still looking.

[Michael Elford]

Alrighty, need to decode the frame, the below is messy, but it appears to work - getting more offset errors which I need to fix in WebMudServer (lines 72-75) and then a unexpected continuation frame error.

Put this in or around line 145 of WebMudServer.class.incin function on_read.

                        // Trim the nasty from WebSocket data (a 0xFF byte appended to every message) //

//                      if ($cObj->getClientType() == GC_WEBSOCKET)

//                              $data = substr($data, 0, strlen($data) - 1);

//DECODE THE FRAME

$len = $masks = $datadec = $decoded = null;

$buffer = $data;

$len = ord ($buffer[1]) & 127;

if ($len === 126) {

  $masks = substr ($buffer, 4, 4);

  $datadec = substr ($buffer, 8);

}

else if ($len === 127) {

  $masks = substr ($buffer, 10, 4);

  $datadec = substr ($buffer, 14);

}

else {

  $masks = substr ($buffer, 2, 4);

  $datadec = substr ($buffer, 6);

}

for ($index = 0; $index < strlen ($datadec); $index++) {

  $decoded .= $datadec[$index] ^ $masks[$index % 4];

}

$data = $decoded;

[Michael Elford]

Getting close now, connects to the mud and data is going back and forward, just not being sent correctly to the client (assume it's to do with the string offset errors in WebMudServer lines 71-75

We need to encode the frames to go to the client...again, it's not pretty and could probably be written 100 times better :)

in WebMudClient.class.inc replace the send function

        function send($buf)

        {

                if ($buf != "") // New messages to send //

            {

                        if (is_resource($this->socket))

                        {

                                //echo "Sending:\n$buf\n";

                                if ($this->clientType == GC_FLASH)

                                {

                                socket_write($this->socket, $buf . chr(0), strlen($buf . chr(0)));

                                } elseif ($this->clientType == GC_WEBSOCKET)

                                {

//$text = base64_encode($buf);

$text = $buf;

    // 0x1 text frame (FIN + opcode)

    $b1 = 0x80 | (0x1 & 0x0f);

    $length = strlen($text);

    if ($length <= 125)

        $header = pack('CC', $b1, $length);

    elseif ($length > 125 && $length < 65536)

        $header = pack('CCS', $b1, 126, $length);

    else

        $header = pack('CCN', $b1, 127, $length);

                                        socket_write($this->socket, $header.$text, strlen($header.$text));

                                }

                    }

            }

        }

[Michael Elford]

Alrighty, up and running...  The encode function was slightly wrong, need to replace

    elseif ($length > 125 && $length < 65536)

       $header = pack('CCn', $b1, 126, $length);

NOTE: the pack changes from 'CCS' to 'CCn'

[Michael Elford]

Just tested on an IOS device, looks like I will need to implement the various different handshakes for WebSockets (ie. IOS doesn't work)

The above works on Version 22.0.1229.79 m of Chrome.

[Michael Elford]

Alrighty, pretty sure I've nailed it.  Attached is the wm_server folder only with all the changes I made, I've tested on Chrome, IExplore and iOS.

Extract the wm_server wherever you put it, configure it as per the original instructions and run it.

Should be happy to connect to any mud you want it to after that.

[Ragnar]

This sounds pretty awesome, thank you!  I'm looking forward to trying it out in the near future.

[Ragnar]

Damn well I've built another quick VM and installed things as before then added your own files to the mix and initially it still generates the same rapid stream of errors when running the 'php -q server.php', I edited the same way as before with some additions of:
Line 127:
                        if (isset($this->clients[$i]) && is_resource($this->clients[$i]->socket))
//                      if (is_resource($this->clients[$i]->socket))

Line 224:
//              if (in_array($this->clients[$i]->socket, $this->read))
                if (isset($this->clients[$i]) && in_array($this->clients[$i]->socket, $this->read))

Got rid of them as usual but it still comes back to the same result where the browser shows a line about socket_error right off the bat and then the server's output eventually declares bad read and kills the connection.  At this point I'm wondering if its just the base OS I'm using, its a fedora variant 'LXDE' and from what I understand its not all that recent either.  Another possibility is I'm not using the right types of browsers (12.0/linux on the host, 15 & 16 on my windows box along with IE 9).  I digress php is a very new language to me as is html 5 so I haven't much background to go on.

[Michael Elford]

Did you use the WM_SERVER folder i've attached to this thread?  

The issues you mentioned were already fixed in my version.  If you've just re-downloaded off the download page, that wont help - you need the one that I attached here.

[Ragnar]

Oh man I hope it wasn't a noob thing like uncompressing the folder to the wrong spot, gimmie a sec :P  (yah I thought I'd injected your stuff but perhaps not...)

[Ragnar]

Okay I definitely sunk the folder into the right location at this point and yes its not spamming me with those errors without my editing but I'm still getting the websocket error on the local host's browser (FF 12)

From the server I'm seeing the following ouput while its running and I try to connect with the local FF12 browser on the VM:
Client 0 connected.

Good handshake for client [0]

Disconnecting 0:  bad read.

At this point I've left all reference to the server name as localhost but I'm wondering about those two reference
/wm_server/server.php within server.php as define("WS_RESOURCE","/wm_server/server.php");   ...in server.php and then
var wshost = "ws://localhost:12346/wm_server/server.php");  .... in  wm_client/js/client.js

Do they just have to match mapping or is there a genuine folder mapping that is relevant to this (sorry noobie at this too)?  As it stands I have wm_server hanging right off the root folder for lack of a better place to put it but does it actually have to also exist within the web root for this?  like does it need to live in /var/www/html/wm_server if /var/www/html is the root folder for the httpd's default site?

[Michael Elford]

I've enabled some debugging on my system, could you go to http://www.geeksters.net/mud and let me know when you've done it, I'll check my logs and see if we can figure out what's going on.  I never tried FF so it could be something unique to that browser.

Hit it a couple of times so I can if it changes (Iexplore and iOS sometimes changed the way the key was sent)

[Ragnar]

Kay the first two connections were from my windows desktop using FF16 and then the third was from the VM (running the redhat with FF12) and they all seem to connect fine.  At this point I'm wondering of my choice of OS to host things thing is the issue, been trying to avoid something like a full blown ubuntu for this but at this point might be worth a try.

Btw nice excessive invalid connections thing :)  Its spammy my VM's browser like nuts :P

[Michael Elford]

Yeah, love that spam.

I've messed with the client files to automatically connect to the Mud, however, I need to put a counter on it so it doesn't keep trying if it fails (more than 3 times say).  I also need to whitelist the WebMud client so it doesn't get blocked for spamming on the mud quite so easily.

FYI only, FF12 behaves the same way as Chrome (reports the same WebSocket implementation in the header)

[Ragnar]

Kay I'm grabbing a ubuntu server iso now just to see if there's a difference, admittedly the fedora distro I've been using for linux VMs is very light-weight but possibly too old for proper httpd with html5, I've gotta head to bed at some point soonish but do want to continue trying this.  I'll report back once I've got the ubuntu server VM up and running with this installed on it.

[Ragnar]

I got a chance to try it again this time using a ubuntu 12.04 server and apache2:  It works, glorious!  Thank you so much for keeping this project going :)

[Ragnar]

and to further that, I also got it working with the original server too, I didn't move the wm_server folder out of web folder this time so I'm guessing the client relies on it being there too.  This is still great progress for me, thanks again.

[Michael Elford]

Interesting, I have that setup with the wm_server as well, however, the wm_server is unreadable by Apache.  And as far as I've read through the code, I haven't seen any reference between the client/server.

As I get to new stages I'll post them up, happy to share code with you if you're interested in any of the things I implement.

Right now I'm working on the client to make it prettier/nicer.  I've got to add an About link to it and I'm changing the way the connectivity is displayed - this will be slow as I have virtually no skills with CSS. 

[Ragnar]

Definitely appreciate the offer and that's the direction I'd like to head in as well once I can sort out one final situation:  I can connect to this thing perfectly within my own network but unfortunately it seems the internet at large cannot get a connection established with the server.php process itself via the client page.  The host is sitting behind a NAT'ed router and I guess now its a matter of figuring out which chunks of this thing run where so I can figure out which address is relevant to what (my public IP vs my private 192.168.1.x range).  I've got both the ports open that should be as well just in case, but I was under the impression that the client page runs its java script locally on my host not on the client's machine themself and it in turn just needs to locally reference the address of itself to connect with the server.php process's bound ports.

So people can reach the client site but the two connected status boxes remain grey for them, hrm.  This would be a lot easier if I just had a public facing server :P

[Ragnar]

And sure enough with more fiddling got it working.

in the server.php I had it bind the hosts' internal IP address but in the three WS connection settings I left it as the domain name pointing to the public address (with port forwarding still in play), then within the client.js I also had it reference the domain name.  The key thing I think was not making the host itself use the domain name as its own name, removing that entry from /etc/hosts I think really fixed it up and let the people connecting deal with the DNS on their own.