Prototype

[xarn]

Hi,

I've currently made a small test using websockets. Does anybody has a server available where we can put stuff? (I mean not only web pages, but being able to install/run programs)

The test is really minimal. It's just login and chat (no password, etc) and is compatible with firefox and chrome. It's quite simple, just a proof of concept.

However, if it should grow, I don't know exactly how to structure it. Especially the client side with the big javascript stuff.

[xarn]

Hello,

here is the example, as promised:

http://50.57.161.126/lobby.html

You can open two tabs and just talk to yourself

The code can be seen at:
http://50.57.161.126/

[aspidites]

Few thoughts:

Pros
- The code is very clean and easy to read.
- I can see your point with the latency being reduced by using websockets. Nice.


Cons
- Perhaps have the message box cleared after message is sent, and have return serve as default action for send.
- Nuke the browser detection. Websockets are available by all major browsers [1]
- I have mixed emotions about (what I presume) is server-side ruby. Save for the case of perhaps cgi-scripts, I'd have concerns about finding a place to deploy such code. After all, you mentioned not having a server to deploy this to in the original post. If ruby was used simply for prototyping, disregard.


[1] http://stackoverflow.com/questions/1253 ... -for-html5

[xarn]

Hi,

First off, thanks for the constructive/positive feedback!

Perhaps have the message box cleared after message is sent, and have return serve as default action for send.

Oh yeah! You say it, that's definitely to do!

Nuke the browser detection. Websockets are available by all major browsers

Well, actually, I don't perform browser detection. The first lines are needed because Firefox instanciates the websocket in a different way than the standart, like chrome does. ...and well, this single line to know if the browser supports it is really not an issue.

I have mixed emotions about (what I presume) is server-side ruby.

I'm willing to switch to any other server side language. If some dev people want to join and have a preference for another language, we can change. As for hosting it, any VPS will do.

I just found the ruby API quite nice for the wesocket and since I had no experience with ruby I thought it would be a good opprtunity to learn something. The python bindings were a bit wacky for my taste and java seems to have several choices available. I'd also be curious to try out scala.

--------------------------------

PS: I currently moved to a place without internet (I'm currently in an internet-cafe), so at the moment I can't really do anything, nor be very responsive.

[snowdrop]

I'm willing to switch to any other server side language. If some dev people want to join and have a preference for another language, we can change.

I don't think there are more coders around than the ones that are already at work on each project. It's your own version of it - the language pick will be your own call. Just make sure it is an open source language and that it can be easily hosted for non-fantasy sums of dollars.... I think VPS:s can be found pretty cheap...

Ask yourself what your goal is - if you want to learn a new language you really want to master then you should maybe pick it if you are patient and really think you will follow through. Else pick one that you already know..

PS: I currently moved to a place without internet (I'm currently in an internet-cafe), so at the moment I can't really do anything, nor be very responsive.

Give us a sign of life every know and then and tell us how it goes... sounds like both exciting and challenging times for you. Shout if you need anything.

[xarn]

Yo, i still don't have internet at my "new place" so I'm relying on friends to go on the net.
I had to highjack the chat demo prototype to make place for a showcase exercise of a potential employer ...in php

The old stuff is in http://50.57.161.126/old but I don't think I restarted the chat server.

Perhaps I'll be able to work a little on wtactics tomorrow ...or even today ...we'll see.

See ya later

[xarn]

Yo! I just wanted to give some sign to see I'm still alive.
...I still didn't had the opportunity to work on it and my life still goes more upside down as ever. However, wtactics still lives in the back of my mind.

By the way, the old demo is back online at http://50.57.161.126


Recent activity

As you now, my plan was to use websockets as the communication protocol.

I worked a little on it and stumbled on the following small issue. Once the page opens, it initiate a connection to the server, and then the browser can interact with the server (login, chat, ...). The little small issue is that when going from one page to another, the connection has to be reinitialized. And when this happens, session information is lost, which basically means that you have to authentify yourself again each time.

In more simplified words, let's say you are logged in as "John" in the lobby. When you go to another page, the connection will be reset, and upon reconnection, it'll be asking "Who are you?" ..."Can you prove you are really john?"

There are two ways to tackle this:
1. either use a single web page, hence a single connection and let javascript handle the content
2. either let different web pages re-authenticate the user each time

Choice

Despite the first is slightly easier at first sight, it is not the most scalable. As the pages and scripts will grow, it is likely to become more maintainable if we separate the pages and the scripts. Therefore 2 was chosen. Moreover, it has 2 other advantages: first, when a connection breaks, it can be resumed. Then, it is more interoperable with surrounding PHP, which is explained later, hence compatible with what Knitter did.

How it works

When logging in, the login/password is also stored at the client side using the "sessionStorage"

Code: Select all

<script type="text/javascript">
sessionStorage.user = "John";
sessionStorage.password = "Smith";
</script> 

Then, whenever a connection has to be established, a re-authentification takes place using the stored data.

Code: Select all

<script type="text/javascript">
ws = new WebSocket("ws://...");
ws.onopen = function() {
                ws.send('login ' + sessionStorage.user + ' ' + sessionStorage.password);
        }
</script>

Integration with PHP

Another advantage is that it can integrate better with surrounding PHP (or other technologies).
Just for information, PHP does things differently: on each request it sends a cookie, and this cookie is used to retrieve the information about the current session ...well, this is the default, they are some other ways to do it also.

To authentify a user, both PHP and the game server needs a sort of database behind. In order to make the websocket connection interoperable with the PHP pages, it is sufficient to connect to the same database.

Future plans

Once I've time I plan to deliver a minimalistic working prototype

[Knitter]

You could just use the standard authentication method with cookie and token ID. It's the usual way to allow users that return to the system to be automatically authenticated, like when you use the "remember me next time" feature on forums and such. It's the same no mater what server-side language you use.

That would allow you to avoid storing the user's password on the browser, you would never store the password thus preventing anyone else from taking it.

As for storing the session info in a coockie, every server-side technology does that unless you specify that you want to user URL encoded session IDs, it's part of the HTTP protocol.

[xarn]

A websocket is very similar to a pure TCP connection, it has nothing to do with the HTTP protocol, nor cookies, etc...

[Knitter]

A websocket is very similar to a pure TCP connection, it has nothing to do with the http protocol, nor cookies, etc...

I know, I was talking about the option to maintain a session between the different pages, it could be made with a normal session using the usual security token approach and that would simply use a cookie without the need to store the password in plain JS or anywhere in browser. Sorry about the confusion.