Динамическое добавление элементов(сообщений форума, например) на страницу.

работают, все окей, нагрузку полинг создает на вашем похапе, не все языки одинаковые, например erlang фреймворк чикага-босс эмулирует вебсокеты без них самих и там все четко, алсо есть разные etag и прочие таймштампы последней модификации

я активно использую tornado + sockjs и на работе и дома, до этого использовал ноду; везде все приемлемо, асинхронность рулит, потоков, конечно, на всех не напасешь

В каком смысле потоков не напасешь, а то я тоже не в теме, но интересно?

смотря какая железяка, конечно

и опять же, какая платформа, не скажу за все, но думаю если на каждое соединение запускать дедушку апача то праздник быстро кончится

Теоретически данный функционал можно реализовать ajax с большим таймаутом или вообще без оного: клиент посылает запрос, а сервер уходит в sleep() (или скажем select() на сокете, через которые вещаются новые посты), и как только появляется новый пост — отвечает на запрос. Главное, чтоб только клиент не перестал ждать ответа. И чтоб запросы не «залипали» на очень долго.

Вот такой вот костыль.

Правильно ли я понимаю, что это сейчас делается через ajax

Правильно.

у клиента висит на таймере проверка

Таймер — уже в прошлом, нонче модны вебсокеты.

нельзя сделать так…

вебсокеты

они пока не работаю

очень даже работают

Да, меня вот всегда беспокоило, что процессов в системе и tcp-портов ограничено, причем цифры в районе 60000, как они собирались на вебсокетах много клиентов обслуживать? Не проще какой-нить igmp поднимать, или всем рулят поп-браузеры, а не комитеты?

P.S. А что там слышно насчет библиотеки для вебсокетов: написали уже, или таки самому, когда понадобится, придется доделывать велосипед?

// естественно, на сервере висит сишный CGI

процессов в системе и tcp-портов ограничено

При этом таки каким-то чудесным образом веб работает…

Это же вроде не должно уменьшить колва сокетов, только их ротацию увеличит.

что процессов в системе и tcp-портов ограничено, причем цифры в районе 60000, как они собирались на вебсокетах много клиентов обслуживать?

скорее всего эти «вебсокеты» ненастоящие, типа как грин-треды.

Он же по принципу запрос-ответ-померла работает, а не на долгосрочных соединениях.

Т.е. если одновременно "постучатся" 65000 человек, сервак сдохнет?

А насчет вебсокетов, что-то у меня была надежда, что, в связи с переходом на 64 бита, таки количество сокетов в системе маленько подымется...

Щас погуглил, похоже загоняюсь — на один порт сервер может принимать любое число подключений, ограничения только в буферах в ядре и файлов на процесс тоже не бесконечно, но их даже по дефолту овер300000. Так что можно на каждого клиента дать по соединению.

Количество самих портов не подымется, так как 16 бит зашито в заголовках ip.

ну типа улимит можно подымать, системы делаются распределенными

Выше в треде вроде ничего тебе на расшифровали попробую по пунктам.

То что ты описал сначала называется поллинг. Проблема поллинга в том, что ты в состоянии спокойствия все равно потребляешь ресурсы процессора сервера бомбардируя его ненужными запросами.

Для решения этой проблемы придумали лонг-поллинг и стримминг. Первый заключается в отправке длительного запроса, на который сервер не отвечает до тех пор пока не захочет что-то сказать. Среди минусов - костыль для HTTP, клиент постоянно отправляет запросы, даже если по идее траффик односторонний со стороны сервера. При большом количестве запросов такой лишней исходящей с клиента информации станет больше и нужно будет городить пакетную обработку. Стримминг - загрузка бесконечной страницы. Или с данными или с тегами <script>, которые будут что-то делать на странице. Костыль большего масштаба, жрет память, тоже ничего хорошего. Но этими двумя способами приходится довольствоваться в унылых старых браузерах. В качестве бонуса к остальным венерическим заболеваниям в некоторых браузерах вам гарантирован бесконечный вращающийся кружочек «Загрузка....» в статусбаре.

Чтобы побороть все костыли придумали новый веб-стандарт - вебсокеты. Все работает икаропки, связь в две стороны без оверхеда, SSL, все что надо работает. Практически 0 лишней информации, все современные браузеры поддерживают.

А теперь сервер-сайд. Если вам не повезло и у вас не event-driver/асинхронный сервер (тут некорректная терминология, но именно эти слова вам нужно искать в документации), то при всякие висящие запросы будут жрать поток. Стоит вам дойти до 1000 потоков и ваш сервер вероятно станет колом. Помощнее железка станет колом быстрее.

Потому вам нужно искать сервер, хорошо работающий в event-driven модели и с качественным web-socket api. Если соединения нагруженые, то вы ясное дело (и все справедливо) упретесь в память или CPU. Но если много соединений относительно спокойные, то можно работать с сотнями тысяч соединений не напрягаясь. Само соединение стоит очень мало и ясное дело количество дескрипторов - не проблема, легко увеличивается в ядре.

Какой ЯП? Тогда можно подсказать что-то по норм event-driven API. Если пока не определено, то

Python https://github.com/heroku-examples/python-websockets-chat/blob/master/chat.py

Node.js http://habrahabr.ru/post/127525/. Кстати, тут socket.io - библиотека, которая делает фоллбек на другие способы связи если у клиента старый браузер.

Java - Java EE 7 Web Sockets, Vert.x

Ruby - Event Machine web-sockets, Socket.IO

Scala - Play 2 Websockets

Наверное быстрее всего будут работать Java/Scala реализации, так как они на очень быстром Netty. Потом Node.js, потом все остальное

socket.io будет реализован в многих ЯП, так как это целый протокол с фоллбеками с веб-сокетов на что-то более примитивное.

потоков, конечно, на всех не напасешь

попахивает кодобыдлом