История изменений

Исправление ~~vertexua~~, 24.11.13 01:26 (текущая версия) :

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

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

Для решения этой проблемы придумали лонг-поллинг и стримминг. Первый заключается в отправке длительного запроса, на который сервер не отвечает до тех пор пока не захочет что-то сказать. Среди минусов - костыль для 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 будет реализован в многих ЯП, так как это целый протокол с фоллбеками с веб-сокетов на что-то более примитивное.

Исходная версия ~~vertexua~~, 24.11.13 01:24: