WebSockets vs raw TCP sockets in Flash

Question

What WebSockets add to raw TCP connection? Why should I use WebSockets?

I'd like to hear cons and pros like:

• Good: WebSockets add some useful things like autoreconnection, session ids, etc.
• Bad: WebSockets add a lot of overhead

I'll have only Flash clients, no need to support Javascript clients.

Solution

You can't do raw sockets from a web application in a browser. Even "raw" socket connections from Flash are not really raw because you have to answer a policy file request to get CORS security (part of the reason for the WebSockets handshake).

After the initial WebSocket handshake, WebSocket messages have two bytes of framing overhead per frame (Hixie-* has '\x00...\xff' and HyBi-07 has two byte header), so the overhead is pretty negligible compared to regular sockets.

The WebSocket handshake is an HTTP compatible Upgrade request so it is easy to integrate WebSockets support into existing web servers and to use existing Web ports (80/443) which means that WebSocket connection can also more easily integrate into existing firewall rules.

The HTTP compatible handshake also means that existing HTTP authentication mechanisms can work transparently with WebSockets. Also, WebSockets can be proxied by existing web proxies with little or no modification.

In the next revision of the WebSockets protocol rev (HyBi-07), their is protection against misbehaving web intermediaries using client to server XOR masking of the payload data.

Things like auto-reconnection, session ids, etc aren't defined in WebSockets although several Javascript frameworks built on WebSockets have this such as Socket.IO. If you are doing WebSockets from Flash applications then you would need to do your own session management or convert an existing session management library to use WebSockets rather than Flash sockets (such be pretty easy conversion).

Update:

Couple of links that might be useful to you or others who land here:

• AS3WebSocket: WebSockets client library for Flash applications.
• web-socket-js: WebSockets fallback/polyfill implemented in Flash for Javascript applications (to add WebSockets support to browsers with Flash but without native WebSockets).

Comments

[moka]

Regarding overhead, it is 2 bytes Minimum, but usually more. From client to server it is additional 4 bytes for mask. As well when data is longer then 126 bytes, you have to add another 4 bytes for uint for length. So it is usually about 10 bytes overhead of data to send. But there is more important thing, is to process this header and do demasking on server side for each message, so you use much more CPU to process data. As well if you create nice serialization from data straight to binary, then it will be much better then using utf8 messages for as example JSON. For flash use raw.

[kanaka]

Maksims, the HyBi working group was very intentional in which mechanism was selected for masking client -> server traffic. Because the mask is included in the frame there is no state to remember, and the running 4 byte XOR is just about the fastest (and efficient) streaming operation across lots or architectures. Also important to note is that server -> client traffic is not ever masked and large data is usually server -> client. Also, 126 -> 65535 byte frames have 2 bytes extra NOT 4 bytes more. Over 65535 is 8 extra bytes. This header overhead will not make measurable real world difference.

[Triynko]

Well what about: "Every new technology comes with a new set of problems. In the case of WebSocket it is the compatibility with proxy servers which mediate HTTP connections in most company networks. The WebSocket protocol uses the HTTP upgrade system (which is normally used for HTTP/SSL) to "upgrade" an HTTP connection to a WebSocket connection. Some proxy servers do not like this and will drop the connection. Thus, even if a given client uses the WebSocket protocol, it may not be possible to establish a connection." - html5rocks.com/en/tutorials/websockets/basics

[Triynko]

And what about the Windows 8/Server 2012 requirement: stackoverflow.com/a/16555158/88409 >>links to>> iis.net/learn/extensions/introduction-to-iis-express/…

[kanaka]

@Triynko, the html5rocks article you link to is 3 years old. The issues mentioned are bugs and most have been or will be fixed in the near future. Also, similar issues exist with the policy request for Flash TCP sockets and are less likely to be addressed now that Flash is considered legacy by most developers. In terms of IIS Express support for WebSockets, that's interesting, but it doesn't prevent you from running a dedicated WebSocket server, so really the situation is no different from Flash TCP sockets (where you would run a dedicated server in most cases anyways).

[Triynko]

I ended up using Websockets, and it works beautifully. Rather than maintaining an AS3 implementation like AS3WebSocket, I opted to use the browser's implementation and just marshall the calls to/from Flash using a base-64-encoded bridge (via ExternalInterface). Overhead is negligable, and it works flawlessly. Unlike JavaScript, ActionScript 3 has type-reflection and a Dictionary object supporting object references as keys. That allowed me to implement full AS3 object serialization, with cyclic references and complete type information, revivable in .NET on the server side, and vice versa.

[Triynko]

My serialization-binding layer supports exact mappings, mirror mappings, and template mappings, right in the Web.config file. For example, exact mappings are in place so the system knows to map AS3 "Object" to .NET "System.System.Dynamic.ExpandoObject", "ByteArray" to "byte[]", and some custom Flash types like "UInt64" to "ulong" and "GUID" to "System.Guid". Template mappings are generic, such as "Vector<T>" to "List<T>" and "Dictionary<K,V>" to "System.Collections.Generic.Dictionary<K,V>". Mirror mappings equate client namespaces with server-side ones, such as "client.*" to "server.*".