По поводу числа сокетов — ulimit -n 1048576 и несколько listen-сокетов вместо одного (например, на разных IP-адресах) дают до миллиона соединений. Это не проблема.
1. Вообще-то, один. Это же событийно-ориентированный сервер.
2. Кажется, нет.
3. Ну все — вряд ли (IE 2.0 или Lynx вряд ли поддерживаются). Но основные, до которых мы смогли дотянуться, — поддерживаются, конечно.
Он позволяет подключаться со стороны JS — на чтение, со стороны PHP — на запись (и на считывание диагностики).
Для приема PHP может подключиться, прикинувшись браузером разве что. Но зачем это? Лучше отправку из браузера на сервер делать обычным аяксом, обычным скриптом.
Ну кроме Long Polling, есть еще Streamin (как раз когда соединение не нужно никогда закрывать). Но только Streaming не работает в IE. Streaming в Realplexor-е в будущем обязательно добавится (правда, для других, небраузерных, целей).
Не страшЁн нам огонь при пожаре,
А страшна паникА при пожаре.
При пожаре гибнУт единицы,
При панИке же — сотни гибнУт.
В том смысле, что проблемы не страшны, страшно, когда они не исправляются. А исправляться они будут, т.к. проект активно используется (и будет использоваться еще кучей людей в OpenSource-community, я подозреваю).
Ну, мы его в Рутвите используем. Насколько стабильно — это только время может показать. Главное, что у него всегда будет активная поддержка, а изменения в код вносить очень легко, благодаря тому, что код на Perl и покрыт автотестами.
В libevent, если обрыв соединения проскочил в промежуток между добавлением события и началом его обработки, в первой же строчке perl-обработчика возникает SIGPIPE, который рушил скрипт и заставлял Realplexor перезапуститься. Я сейчас поставил заплатку на это (просто игнорируется сигнал, т.к. дальше по коду нужные проверки имеются).
Стоп, стоп. На демо-страницы входящие сообщения принимает не Realplexor, а PHP-скрипт обычным аяксом. И уже этот PHP-скрипт отправляет данные в Realplexor.
2. Кажется, нет.
3. Ну все — вряд ли (IE 2.0 или Lynx вряд ли поддерживаются). Но основные, до которых мы смогли дотянуться, — поддерживаются, конечно.
Для приема PHP может подключиться, прикинувшись браузером разве что. Но зачем это? Лучше отправку из браузера на сервер делать обычным аяксом, обычным скриптом.
Не страшЁн нам огонь при пожаре,
А страшна паникА при пожаре.
При пожаре гибнУт единицы,
При панИке же — сотни гибнУт.
В том смысле, что проблемы не страшны, страшно, когда они не исправляются. А исправляться они будут, т.к. проект активно используется (и будет использоваться еще кучей людей в OpenSource-community, я подозреваю).