I’m in the process of porting my gamekit based engine via emscripten to javascript which works thanks to the ogre3d’s current version 1.10 pretty good (thanks to wolfmanfx for his efforts). I wrote a module for ois to handle the input (mouse/keyboard) not perfect,yet but sufficient for the first tests. Maybe I should have tried to use sdl instead but was not quite sure how to initalize events only.
Still thread- and socket-handling todo. Sockets compiled without any problem BUT they are mapped to websockets in the javascript world. Websockets are slightly different from normal tcp-sockets. The raw data is embedded into a framebased protocol after a http-handshake occured.
I guess there won’t be a problem if I would have had also a c++-server that I would want to compile to js as well (not sure if that is a realtistic scenario 
). At the moment I’m using a java reddwarf-server(short:RDS and formerly known as sun’s gameserver project-darkstar) which was canceled at once as soon as oracle took over sun and which is obviously not build to accept websockets. Not sure if ws existed at these days at all.
I found a very good java-library which can handle websockets. First you specify a callback handler for different events like onConnectionOpen, onMessage, onWriteDemand and onClose and then you can just pump a ByteBuffer into the lib which handles the decoding and calls the relevant callbacks in which you “just” have to do the right things
The only problem is that I didn’t had too much knowledge of reddwarf-servers internal process. RDS is mainly build to be highly multicore but abstract this behaviour from the server-user. So the kernel is mainly build with lots of async-concepts which I first had to learn before I could really extend the server.
Basically there is one main concept of delegating completion-handlers which has a start-method and a completion method. Those are stacked together so that the handler on top only passes its data to the lower one when the resulting data is ready. e.g. there is one handler A to read from a tcp-channel and another one B which is coupled with A and once A has its result B gets informed and can process until its result is ready and can be passed to the next underlying handler.
I basically wrote one such handler that sits between the handler which reads raw data from a socket-channel and the one that reads the raw data until a rds-message is complete. My handler takes the raw data, first checks if it is a websocket at all, if not just pass the data one to one to the next handler, if it is a websocket, make the handshake to the client-websocket,pump all incoming data into the websocket-decoder and then pass this data to underlying handler.
Took me some effort, but first tests are now working. All the unsucessfull attempts were still valueable to get more insights into the server kernel.
