|
On 5/24/2013 9:23 AM, Daurnimator wrote:I was under the impression they were using OpenResty, though apparently they weren't, and they listed long polling as a "problem" on the slides, so I was wondering if they'd since found a solution.
How is long polling a problem?
I guess the only problem I'm aware of is that there isn't a nice prepackaged library that handles long polling ("Comet" [1] -- something like socket.io [2]) reliably across browsers. Ideally there would be a WebSocket code path as well. A bit of Googling finds a module for Nginx that supports websockets [3], but with no OpenResty support available.
So it looks like my current solution would be one of :
1) Stick with simple long polling in OpenResty and implement the handling myself entirely in _javascript_. I'd rather not, since even though long polling isn't exactly rocket science, it strikes me as something prone to browser-specific issues. Additionally, I'm led to believe the server load is higher with long polling than with WebSockets, and I know the latency isn't as good if two messages arrive in quick succession.
2) Switch to Mongrel2/Tir from OpenResty, though it's not clear to me that Tir support for WebSockets is first class yet. Documentation is nonexistent, as far as I can tell, and support for existing _javascript_ libraries is an unknown.
3) Switch to Node.js so I can use socket.io without having to reinvent the server or client side of that equation.
#s 1 and 2 keep me with Lua, which is important to me, but if it turns out that #3 gives me significantly better scalability on a single server (through the use of WebSockets), then I'll swallow my dislike of JS and use it. #3 sounds like the "it just works" solution, which is very attractive.
Tim
[1] http://en.wikipedia.org/wiki/Comet_%28programming%29
[2] http://socket.io/
[3] https://github.com/wandenberg/nginx-push-stream-module