I wrote a server-side WebSocket layer on top of normal sockets at work with the help of this blog post (http://www.altdev.co/2012/01/23/writing-your-own-websocket-server/) and the WebSocket specification, unfortunately I the code isn't open source, but it's doable in at most a few days.
Basically you can take a 'normal' TCP server, and after a client connects it will send a special HTTP header, the server sends a special HTTP response back, and from then on the connection will act like a normal TCP connection, but with message framing provided by the websocket protocol. If you already have built your own messaging layer on top of TCP it is relatively easy to replace your own connection handshake and message framing with WebSocket's. The way we use this is to have one TCP server which accepts connections from native clients on one port, and connections from emscripten clients (running websocket protocol) on another port, and have only different code layers for the 2 different handshakes and message framing (either our own custom built framing for native clients, or WebSocket's framing for websocket clients). All the higher-level code on server and client-side are the same. Cheers, -Floh. Am Freitag, 27. Juni 2014 15:08:09 UTC+2 schrieb Karsten Pedersen: > > Hi, > > For a project of mine (A reimplementation of the Unity 4.x API - > http://www.mutiny3d.org) I have been looking at ways to use sockets in > ways as similar as possible to BSD / UNIX sockets. I understand that due to > security limitations in a web browser it is not possible to listen for > connections. I also understand that the connections use the websocket > protocol rather than raw tcp / udp packets. > > I can deal with the above differences because so far some excellent work > has been put into the clientside sockets API and it does seem to work. > However, what I find most fiddly is developing the serverside websocket > server (and integrating with my existing code) or using solutions such as > wsproxy. Unless I am missing something, I have noticed that websocket > server libraries in general are often very overengineered. > > So I perhaps propose the idea that listen(2) and accept(2) could be > implemented (and work when run via node.js rather than a web browser) but > they actually provide the websocket protocol behind the scenes rather than > the traditional raw protocol. > > Perhaps this idea has already been implemented? If not and the idea could > potentially be useful for others (perhaps even inclusion upstream), I am > more than happy to give it a shot to implement myself. My Javascript code > is horrendous but I am hoping I can get by with my C or C++ instead. > > Best regards, > > Karsten > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
