#quickio

But why yet another WebSocket/HTTP long polling server? Well, when we first started looking into the realtime problem, we were, as I'm sure you're guessing, drawn to Node.js+SocketIO and its brethren, but we ran into a problem: handling millions of simultaneous users was next to impossible. While those technologies are great for handling your average website, we have many orders of magnitude more users. So we started looking around, and we couldn't find anything that did everything we needed. 

And we started from scratch. Even in the early stages, QuickIO proved to be far more scalable and reliable than any other technology, but then again, when you're building a lightweight server in C, that tends to happen. Also, rather than relying on existing libraries that limit the server to a single thread and have all sorts of other restrictions, QuickIO focuses on handling clients in whatever threads are available with minimal (and often times no!) locking.

On top of that, QuickIO provides some really awesome user-level features, including:

A pluggable application system for running multiple services in the same server process at once.

A scalable pub-sub system for sending events to tons of clients in realtime.

Stateful callbacks and event conversations with clients.

High-level memory management for DOS protection.

Simple memory pooling for better efficiency.

Graphite and Nagios reporting.

Client libraries in Java, C/C++, JavaScript, Objective-C, and (partially) Go.

And JSON. JSON everywhere.

We've had QuickIO running in production for the past year or so, and having handled billions of events with no downtime, it's time to share the wealth. Head on over to GitHub to check out the source and give it a run. Keep in mind that, for now, it only runs on Linux (with epoll).