Trabajé en juegos para redes sociales algunos años atrás y solíamos abrir conexiones de socket (por medio de flash, ya que no existían aun los websockets) para cada uno de nuestros usuarios. En un punto llegamos a tener hasta 500.000 usuarios en linea al mismo tiempo y nuestro servidor de envío (el que mantenía las conexiones abiertas para los clientes) usaba apenas el 10% del cpu. El servidor fue construido con un eventmachine sobre MRI. Eventmachine en linux puede usar el api de e-poll. Este básicamente registra todas las operaciones de io por sockets. Por dar un ejemplo, Nginx está construido de una manera parecida. Usando esto podemos escalar a millones de conexiones en una sola máquina.(Google el problema del C10k , o entra a http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html) en resumen, correr un servidor con eventos debería manejar múltiples conecciones abiertas sin problemas. La parte de manejar el IO es la parte fácil, uno de los problemas con los que te puedes encontrar es cuando tienes muchos usuarios suscritos a un misma cantidad de datos, ya que podrías terminar saturando la conexión de red en actualización demasiado grandes. Estamos trabajando en un bus de datos distribuido (similar al que existe en vert.x) para permitir actualizaciones distribuidas y conexiones a través de varias máquinas. En los servidores thin y goliath puedes obtener un thread por cada request de rack, pero todos los requests de websockets pueden correr en un solo thread y usar un io por eventos para manejar el envío de resultados. También me gustaría integrar vert.x con jruby para hacer cosas similares. Espero que esto halla respondido algunas de sus preguntas. Existen muchos problemas difíciles en Volt por resolver, pero pienso que manejar la persistencia de las conexiones no es uno de ellos. Para la mayoría de los casos esto es resuelto gracias a epoll y el O(1) linux scheduler.