royaltm / em-websocket

EventMachine based WebSocket server

EM-WebSocket

EventMachine based, async, Ruby WebSocket server. Take a look at examples directory, or check out the blog post below:

• Ruby & Websockets: TCP for the Web

Simple server example

EventMachine.run {

    EventMachine::WebSocket.start(:host => "0.0.0.0", :port => 8080) do |ws|
        ws.onopen {
          puts "WebSocket connection open"

          # publish message to the client
          ws.send "Hello Client"
        }

        ws.onclose { puts "Connection closed" }
        ws.onmessage { |msg|
          puts "Recieved message: #{msg}"
          ws.send "Pong: #{msg}"
        }
    end
}

Secure server

It is possible to accept secure wss:// connections by passing :secure => true when opening the connection. Safari 5 does not currently support prompting on untrusted SSL certificates therefore using signed certificates is highly recommended. Pass a :tls_options hash containing keys as described in http://eventmachine.rubyforge.org/EventMachine/Connection.html#M000296

For example,

EventMachine::WebSocket.start({
    :host => "0.0.0.0",
    :port => 443,
    :secure => true,
    :tls_options => {
      :private_key_file => "/private/key",
      :cert_chain_file => "/ssl/certificate"
    }
}) do |ws|
...
end

Running behind an SSL Proxy/Terminator, like Stunnel

The :secure_proxy => true option makes it possible to run correctly when behind a secure SSL proxy/terminator like Stunnel. When setting :secure_proxy => true, any reponse from the em-websocket which contains the websocket url will use the wss:// url scheme. None of the traffic is encrypted.

This option is necessary when using websockets with an SSL proxy/terminator on Safari 5.1.x or earlier, and also on Safari in iOS 5.x and earlier. Most versions of Chrome, Safari 5.2, and Safari in iOS 6 do not appear to have this problem.

For example,

EventMachine::WebSocket.start({
    :host => "0.0.0.0",
    :port => 8080,
    :secure_proxy => true
}) do |ws|
...
end

Handling errors

There are two kinds of errors that need to be handled - errors caused by incompatible WebSocket clients sending invalid data and errors in application code. They are handled as follows:

Errors caused by invalid WebSocket data (for example invalid errors in the WebSocket handshake or invalid message frames) raise errors which descend from EventMachine::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. However it is possible to be notified in application code on such errors by including an onerror callback.

ws.onerror { |error|
  if e.kind_of?(EM::WebSocket::WebSocketError)
    ...
  end
}

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 decendant from EventMachine::WebSocket::WebSocketError.

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

Examples & Projects using em-websocket

• Pusher - Realtime client push
• Livereload - LiveReload applies CSS/JS changes to Safari or Chrome w/o reloading
• Twitter AMQP WebSocket Example
• examples/multicast.rb - broadcast all ruby tweets to all subscribers
• examples/echo.rb - server <> client exchange via a websocket

License

The MIT License - Copyright (c) 2009 Ilya Grigorik