Switched to websocket/driver and improved websocket handling

[robertjpayne]

This pull request should be considered a WIP, I just wanted to open it for some feedback and sharing.

In general I found WebSocket support in Reel to be a tad flaky and hard to get working since there are not many good examples of keeping a long running persistent WebSocket open in Reel.

This pull request does the following:

• Complete re-write of the websocket handler
• Uses websocket/driver instead of websocket_parser
• Detaches the connection instead of just hijacking the socket
• Easy support for long running persistent connection

What I would still like to achieve with websocket support in reel:

• Automatic pinging of client from server if connection is idle for 30s or more
• A way to signal and interrupt the websocket outside of client disconnect/closing
• Specs ( I'm horrible at writing specs )
• Examples ( Lots of examples on how to use this properly and easily! )

[robertjpayne]

For anyone wanting to potentially use this without integrating the pull request I have a standalone handler here:

https://gist.github.com/robertjpayne/6961149

Unfortunately this will not integrate with webmachine nicely.

[tarcieri]

Nice! Thanks for doing this! This is something we have planned on for awhile but never had time to do.

It looks like all the tests are failing though?

NameError:
       uninitialized constant WebSocket::ClientHandshake

[robertjpayne]

I'll have a look at the tests, this pull request is very much a work in progress too. The actor that captures the WebSocket is pretty much locked onto the socket so I'm not entirely sure how useful it will be without some mechanism to feed messages back to the client or if that is something we should let others solve!

I'd love to port FAYE to use Celluloid/Reel instead of EventMachine but that may take a bit more effort than I have time for right now too.

[tarcieri]

@robertjpayne having connections locked to a specific actor is intended behavior. It should be possible to send messages when callbacks fire within that specific actor, as well as set timers, although timers are presently broken with Celluloid::IO (see celluloid/celluloid-io#56)

[robertjpayne]

Just for anyone that may be watching this I'm struggling to get a spec setup suitable for testing the websocket driver as it blocks the calling thread.

@tarcieri I'm not sure if you could help out here, maybe we can hash it out over IRC but I'm not having any luck bending rspec to my will to avoid things blowing up like mad and getting proper testing out of the specs.

[Asmod4n]

blocking the calling thread means Reel can only handle one connection?
Solved: https://gist.github.com/Asmod4n/8654523 :)

[tarcieri]

@Asmod4n that makes a separate thread per Websocket connection. Ideally they could all use the same thread.

@robertjpayne I'd be happy to help pair with you over IRC to get this finished. It'd be nice for Reel to have solid Websocket support

[Sen]

hi @robertjpayne @tarcieri , any progress about this feature?

[tarcieri]

Nope :|

[Asmod4n]

I belive you would want to use @request.body here and not the string representation.

[Asmod4n]

Have made a small gist on how to use the websocket-driver lib with celluloid-io: https://gist.github.com/Asmod4n/241c84ef31df921b31e9

@tarcieri @robertjpayne

[tarcieri]

Fixed in #166