Расскажите про Comet

а так же выкриков «perl мёртв» и «апач ненужен»

CGI мертв и не нужен, остальные ок

пуша как такового нет, есть полинг и (веб)сокеты. мой совет — бери sockjs, а если задача только в очередь класть, можешь и на rabbitmq глянуть, там они прямо из коробки, со stomp протоколом, так что реверспроксанешь и даже дописывать ничего не прийдется. ключевые слова, вкратце.

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

опрос прогресса это лучшая стратегия, запись в поток и флуш с сервера, проверка readyState на клиенте

короче ты ничего не пропустил)

хочется сделать красиво, по уму, через новомодный HTTP Push.

У меня Perl (но без апача) на сервере. На клиенте Websocket. Server-Sent Events считаю слишком хипстерским. Прекрасно работает.

но без апача

Это как? Как без http-сервера?

/me апач видит только на щаредах. сам давно переехал на nginx+php-fpm, очень доволен.

Это как? Как без http-сервера?

У меня hypnotoad, это http-сервер из Mojolicious.

если ие ненужно то бери вебсокеты и вперед

Push это грубо говоря долго висящий коннект, который сервер не закрыват и в который время от времени выплевывает информацию.

Классический пример - в html пишем

<script src="myscript.pl"></script>

А в myscript.pl пишем браузеру любые интересующим нас js-вызовы, не возвращая управление.

Например так (перл не помню, напишу на псевдокоде):

while (true) {
    sleep(1);
    var progress = get_progress();
    response.send('js_update_progress(' + progress + ');');
}

Браузер грузит это дело как жаваскрипт, по мере поступления данных выполняет их, ну а дальше уже дело техники.

Есть и другие способы добиться этого, подробнее в википедии. Ну а либы — чтобы обернуть это все в удобоваримый вид.

И, да, висящие коннекты не очень сочетаются с cgi, от тысячи-другой юзеров онлайн сервер может начать кряхтеть.

для вебсокетов рукопожатие делается через http(s) запрос. а дальше это уже отдельный от http протокол. https://github.com/andrew-aladev/talloc-visualization/blob/master/backend/src... на соответствие стандарту не претендую, но принцип очень простой.

SSE подойдет?

demo example:

http://www.w3schools.com/html/tryit.asp?filename=tryhtml5_sse

Ради прогрессбара вебсокеты не нужны. Это как на майбахе возить мешки картошки. Вот интересно, клиент завел задачу рисуется прогресс и бах у клиента вырубили свет. Через два часа он снова заходит и увидит ли он нотификацию, что задача выполнилась или нет? Если приложение слишком умное сделался rollback? А клиент об этом как-нибудь узнает?

Те, кто юзают веб-сокеты ради прогрессбара - ССЗБ. Это отличная лазейка для ддос, всего-то симулируй very slow connections.

по мере поступления данных выполняет их

Глупость, браузер не запустит скрипт пока его целиком не распарсит.

Ты пытаешься long-polling описать, но и тут не прав. Если есть данные, сервер ответ на такой запрос сразу отправит, если нет - будет ждать не закрывая соединение. А клиент получив ответ немедленно посылает новый запрос. И это не push, только костыль на него похожий.

Apache MPM event должен справится, но лучше взять nginx.

http://habrahabr.ru/post/76144/ пример на перле для вебчата и nginx.

Comet — любая модель работы веб-приложения, при которой постоянное HTTP-соединение позволяет веб-серверу отправлять (push) данные браузеру без дополнительного запроса со стороны браузера.

Ваш К.О. :D

по-моему это невероятно неоправданный оверхед, перед этим происходит форк как я понимаю?

твое приложение и есть хттп сервер

В смысле - я сам должен определять виртуалхосты, сам делать ssl, всё сам? Не хочу я всё сам.

Ваш К.О.

Спасибо, капитан. Куда же я без вас, без цитат с википедии-то...

всего-то симулируй very slow connections

А если перевести на русский?

это британский танк 7-го уровня кажется

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

Кто сказал «риалтайм»? Я не говорил «риалтайм».

я тебе сказал как делают люди которые через все это прошли и работают в условиях приближенных, если тебе нужен apache можно и broadcast.json перлом записывать а в браузере его обновлять

На русском это так и переводится: очень медленные соединения. Как понятно из названия они не являются маловероятной вещью: адсл, gprs, диалап? — все это еще будет долго жить. Тем не менее, их поведение можно симулировать.

Для тебя это означает, что по твоим расчетам на один прогрессбар ты должен отправить 3 пакета по 100 байт, допустим. И всего за минуту. Вв случае медленных соединений твой сервак может отослать в 10 раз больше данных, ну так устроен TCP, что он гарантирует доставку данных и поэтому пытается в случае неудачи повторно все слать. Плюс ко всему увеличится время такого соединения.

Поэтому, первое к чему надо быть готовым, что у тебя будут десятки-сотни тысяч соединений. Во-вторых, эти соединения нельзя «килять» серверу (только если с опцией so_linger aka rst). В-третьих, все зависит от архитектуры приложения, в частности сколько памяти выделяется под каждое соединение. В-четвертых, это вовсе не проблемы если ты не нищеброд и готов покупать сервера пачками.

Сейчас отображение прогресса выполнения задачи делается периодическим опросом, хочется сделать красиво, по уму, через новомодный HTTP Push.

По сути периодический опрос в лице long polling и есть один из вариантов HTTP Push, разве нет?

long polling не особо переодический запрос так то.