

The new Rack socket hijacking API - ninh
http://blog.phusion.nl/2013/01/23/the-new-rack-socket-hijacking-api

======
RyanZAG
This would scale very badly, correct? If you have to hijack the connection for
each client and then spend awhile doing a task (waiting for a task to
complete, etc), then your whole webserver thread is going to be sitting there
waiting.

~~~
alexkus
How it scales is an interesting question.

Could it, for example, replace a COMET server that is maintaining 100
connections (all doing long polling)? 1000? 10000?

Could it also be hacked into doing Websockets upgrade (and subsequently
maintaining a large number of concurrent websockets conns)?

~~~
FooBarWidget
Yes and yes, but it depends on your web server.

For example, while this API allows you to implement the WebSocket protocol,
Nginx's input buffering will interfere with it.

------
zrail
I wonder if Heroku will add support for this. It'd be pretty nice to be able
to just deal with arbitrary sockets there instead of being limited to just
HTTP.

~~~
tenderlove
It depends on the webserver you use, not Heroku. The webserver must implement
the hijacking API of Rack.

Also, you don't necessarily have to run an HTTP server on Heroku. They'll run
whatever you want (as long as you change your procfile), so I think you can
just go nuts. I _think_ the only restriction is that you can't have the socket
open for more than 30 seconds (though that may be 30 seconds of the socket
being idle).

