I heard about the Web Sockets Interface in the HTML file specification from a relevant question here.
It sounds very promising!
I don't understand how it works does it still use the HTTP protocol and works-around it or does it work something like TCP sockets?
views:
484answers:
2The Web Socket protocol is a TCP based protocol, but it is design to downgrade to HTTP. There is also an HTTP handshake that asks the server to upgrade to the Web Sockets protocol. So if the server supports it, then a duplexed TCP connection will be used, otherwise resort to HTTP and the Comet hacks for that.
It is not HTTP, nor is it plain TCP sockets. It is designed to get the low overhead of regular socket connections (AJAX/COMET are very high overhead), but without sacrificing some of the browser security principles that have been developed over the past few years.
The initial WebSockets handshake looks a lot like HTTP. This will make it easier for existing HTTP proxies and web server to support incoming WebSockets connections and do the right thing with them (i.e. forwarding them on to the real handler). But after a successful handshake (which includes exchange and validation of origin information), the connection stays open and becomes bidirectional.
Each packet of data (whether sent from server or from the client) begins with a '\x00' (zero byte), is followed by UTF-8 encoded data and ends with a '\xff' (all ones byte).
The current draft standard is here: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76
You also might find the wsproxy included in noVNC to be useful as a reference. wsproxy is a generic WebSockets to TCP socket proxy. There is both a C and python version of wsproxy included with noVNC.