> The separate server uses threads or non-blocking I/O? I guess with > Ruby's current threading model you could scale to a couple of thousand > connections but threading is only going to take you about that far. > (Having native threads is going to limit it much earlier.)
Currently just using threads. But this is stupid simple stuff. The socket server is tiny. It's an obvious fit to rewrite it in C to get blazing speed. All the socket server does is match IDs to sockets and pass messages through. > What about temporary disconnects from the client? (HTTP infrastructure > usually doesn't like long-lived connections.) Is there a queuing > system in place so the client will receive those messages when he > reconnects? Doesn't have to be rocket science but I do think this is a > problem that needs to be solved. We haven't yet digged into the failure modes. But it shouldn't be that hard to do. Currently it just throws away the message if the socket isn't there. So there are no retry semantics. > You guys using this in Campfire? Planning to? No and no. Going sockets add complexity. Which is fine when you need it, but Campfire doesn't. You can make polling really, really cheap. And we did. But I could definitely see us using it for other applications. Say 3 people working in real-time on a single todo list. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
