Protocols supported, and protocol specific functionality

Supports all WebSocket protocols in use in the wild (and a few that are not): drafts 75, 76, 1-17, rfc.

While some of the changes between protocols are unimportant from the point of view of application developers, a few drafts did introduce new functionality. It's possible to easily test for this functionality by using

Ping & pong supported

Call ws.pingable? to check whether ping & pong is supported by the protocol in use.

It's possible to send a ping frame (ws.ping(body = '')), which the client must respond to with a pong, or the server can send an unsolicited pong frame (ws.pong(body = '')) which the client should not respond to. These methods can be used regardless of protocol version; they return true if the protocol supports ping&pong or false otherwise.

When receiving a ping, the server will automatically respond with a pong as the spec requires (so you should not write an onping handler that replies with a pong), however it is possible to bind to ping & pong events if desired by using the onping and onpong methods.

Close codes and reasons

Early protocols just close the TCP connection, draft 3 introduced a close handshake, and draft 6 added close codes and reasons to the close handshake. Call ws.supports_close_codes? to check whether close codes are supported (i.e. the protocol version is 6 or above).

The onclose callback is passed a hash which may contain following keys (depending on the protocol version):

was_clean: boolean indicating whether the connection was closed via the close handshake.

code: the close code. There are two special close codes which the server may set (as defined in the WebSocket spec):

range 3xxx: reserved for libraries, frameworks, and applications (and can be registered with IANA)

range 4xxx: for private use

If unsure use a code in the 4xxx range. em-websocket may also close a connection with one of the following close codes:

1002: WebSocket protocol error.

1009: Message too big to process. By default em-websocket will accept frames up to 10MB in size. If a frame is larger than this the connection will be closed without reading the frame data. The limit can be overriden globally (EM::WebSocket.max_frame_size = bytes) or on a specific connection (ws.max_frame_size = bytes).

Handling errors

There are two kinds of errors that need to be handled -- WebSocket protocol errors and errors in application code.

WebSocket protocol errors (for example invalid data in the handshake or invalid message frames) raise errors which descend from EM::WebSocket::WebSocketError. Such errors are rescued internally and the WebSocket connection will be closed immediately or an error code sent to the browser in accordance to the WebSocket specification. It is possible to be notified in application code of such errors by including an onerror callback.

Application errors are treated differently. If no onerror callback has been defined these errors will propagate to the EventMachine reactor, typically causing your program to terminate. If you wish to handle exceptions, simply supply an onerror callback and check for exceptions which are not descendant from EM::WebSocket::WebSocketError.

It is also possible to log all errors when developing by including the :debug => true option when initialising the WebSocket server.

Emulating WebSockets in older browsers

It is possible to emulate WebSockets in older browsers using flash emulation. For example take a look at the web-socket-js project.

Using flash emulation does require some minimal support from em-websocket which is enabled by default. If flash connects to the WebSocket port and requests a policy file (which it will do if it fails to receive a policy file on port 843 after a timeout), em-websocket will return one. Also see https://github.com/igrigorik/em-websocket/issues/61 for an example policy file server which you can run on port 843.