Meeting with tutor, and first code session

Today was very productive! Our tutor suggested we got started with the coding, something we had not planned to do just yet, but turned out very productive. The general idea was to work out the rough part of the application to easier be able to plan the project. In an earlier post I supplied some sample code for connecting Erlang to Spidermonkey using erlang_js, today we integrated this code with an OTP server. This means we can execute javascript on our OTP server and return the result to the callee. The earlier sample code evolved into two functions residing in js_runner.erl which will be responsible for the execution of javascript. When executing the javascript, the js:call function expects all parameters to be in binary form, which became a bit of a headache. The client sends data in UTF8 form to the server, and the server must then somehow convert this UTF8 data to a binary string, "abc" becomes <<"abc>> in other words. The problem we had with this was that term_to_binary/1 does not support unicode or UTF8. Later we discovered the unicode library, and also that list_to_binary/1 does support unicode. Currently the server uses TCP for communication, mainly because it is easier to test. We use telnet, and a custom client developed by Jeena in Ruby. This client is basically a mock game for our game server, and in the future, games will use UDP to talk to the server. We have also identified that we should use Mnesia for our data store, and not as previously stated ETS. ETS is not suitable in a distributed environment while Mnesia is. This work has not yet begun, however Mathias has taken it upon himself to investigate it and produce some sample code. Work continues on the SpiderMonkey side regarding the JS -> Erlang bindings, we are investigating whether we should implement this in erlang_js or work around it some other way.

Time Report
We spent today, from 11 - 16.30 (5.5h) working on this.

Fourth meeting

meeting time: 12:30 - 15:30 _Server interface_ - Easy to use - Powerful - Slow communication(Low proiority) - Fast communication(High priority) - Send key:values (nick, pms) - Register callback (serverside) ball is moving, update graphics - Inlogg med cookies or passwords - Master Cookie, optional - loggout /shutdown same cookie as loggin - upload methods - spidermonkey _Internal_Interfaces_ - Javascript as pure text in memory - access the world through a global object - Store the world as ETS(erlang) JS -> ERL -> ETS ->JS -> ... _World_API_ API usage example: users = [users] world.p1.px = 2 world.foo.__set(2) user.send(2) world.foo.__setter = function (a) { erl_set("foo", 2) } Safety issues: - Bad javascript - No IO - ETS Communication requirements: Communication between everyone, single or multiple clients. _Server_interface_ runtime flow: 1. _Initialization_phase_ 2. Message_phase_ -dictionary(JSON,PList, ...) 3. _User_login/logout_

Our second meeting

We have decided that SpiderMonkey is a good way for us to run javascript. erlang_js seems to be a good way to interact with javascript. We also found out that SpiderMonkey will not supply us with the browser features it usually has, and this is good, because we do not want them. In addition to SpiderMonkey, we should consider NodeJS, it may have other features, such as communication via sockets which we can use. Socket communication may be better suited than pipes. The communication between client and server (and the other way around) needs to be fast. We have decided to use UDP as our underlying protocol, but the protocol on top of UDP should be swappable via a protocol module. We have a few candidates for these "application level protocols"

• JSON
• Binary PLIST
• BSON

JSON is good because

• It is easy to construct
• easy to read
• readily parsable in javascript

It is bad because

• There will be a lot of overhead

Now, on the other hand, the two other protocols are quite small, but they are difficult to construct, and there's no built in support for them in javascript. We decided to make the server protocol independent, and to create at first a module for JSON allowing us to send messages back and forth in an easily debuggable manner. The lower levels of networking will be handled outside the JSON/other-protocols module. We need to find a way to replicate SpiderMonkey runtimes. We plan to keep at least two runtimes alive, and if one crashes, we should replicate it and produce an exact copy. We have not yet decided how to do this.

First meeting

Protocol: Stateful protocol JSON UDP Store session id (sockets) Game node hierarchy: Game → Group → Player (perhaps a lobby would be needed) Different game categories: Chess Farmville Quake We are about to focus to support more games like Chess and Farmville and less on Quake. Project is going towards a generic SpiderMonkey Server than a Generic game server. Is the server going to have one SpiderMonkey instance or multiple? More means safety. We strive for hundreds but not more. Libraries: OTP (Security) SpiderMonkey (Mozilla's C implementation of JavaScript)

Time report

8 hours