Просто используй Mongrel2.

Хочу в apache

В общем, скачал я модули к апачу здесь. Установил их. Тесты работают. Но сами тесты - модули апача. А как сделать свое - непонятно.

Я-то думал, все будет так же элементарно, как с CGI, с той лишь разницей, что нужно будет создать сокет для общения CGI и клиента...

Неужели никто с вебсокетами не связывался?

>Неужели никто с вебсокетами не связывался?

Так они ж нигде не работают.

Это не подойдёт?

http://git.warmcat.com/cgi-bin/cgit/libwebsockets/tree/test-server/test-server.c

Тест (модуль для апача) работает. Остается понять, как подключить свое, не создавая модуль для апача.

Это не подойдёт?

Нет, это - самостоятельный сервер, слушающий вебсокеты. А у меня в качестве сервера работает апач.

Оно, не? http://habrahabr.ru/blogs/webdev/82140/

Первая же ссылка из Гугла. В любом случае тебе требуется написать что-то постоянно слушающее конкретный порт, а это значит, что оно должно быть постоянно запущено.

nginx + spawn-fcgi и нахер ненужен ваш апач :3

Не оно, конечно.

А насчет того, что постоянно слушать порт - не нужно это: по веб-запросу от клиента запускается демон, который и открывает сокет. Вот только проблема в том, что я ни сном, ни духом, как это написать. Как модуль апача - можно реализовать. Но это - хреновый вариант (особенно если нужно несколько сервисов сделать).

что-то я тогда не понимаю зачем вообще тут сокеты?

Чтобы поддерживать неопределенное время (часы, дни, недели...) соединение с клиентом.

А основная мысль - использовать вебсокеты для асинхронного соединения (т.к. при интенсивном обмене сообщениями без вебсокетов часть сообщений теряется из-за невозможности реализации асинхронного соединения).

> А насчет того, что постоянно слушать порт - не нужно это: по веб-запросу от клиента запускается демон, который и открывает сокет.

Так что-то же должно слушать порт, чтобы получить это самое:

по веб-запросу от клиента

Что никак не противоречит, а лишь подтверждает то, что я сказал.

Вкратце дополню. Мысль такая: клиент осуществляет соединение с сервером посредством обычного POST-запроса на обычный сишный CGI. В ответ приходит адрес, по которому клиент может открыть вебсокет для соединения с сервером. Далее все изменения в управлении железяками клиент производит через вебсокеты, через них же в почти реальном времени ему приходят сообщения.

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

_________

//wfrr

Аццкий изврат. Напиши шо у тебя за язык и сколько ресурсов на сервер - сколько клиентов одновременно будут сервер мучить.

_________

//wfrr

Так что-то же должно слушать порт, чтобы получить это самое:

по веб-запросу от клиента

Что никак не противоречит, а лишь подтверждает то, что я сказал.

апач постоянно слушает восьмидесятый и четыреста сорок третий порты.

Язык - естественно, С. Клиентов - один управляющий (т.к. больше одного нельзя), плюс сколько угодно read-only. Им вебсокеты не нужны.

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

Как всегда, хочется помучаться и использовать что-то неподдерживаемое?)

Используй comet, стабильнее вебсокетов, работа с ним намного проще как на клиенте, так и на сервере.

> что пока стандартное соединение не будет закрыто, клиент полученные данные обработать не сможет.
сможет, но это тоже костыль

Вебсокеты вот вот будут стандартизированы. А comet - какой-то убогий костыль, не лучше флешь.

>что пока стандартное соединение не будет закрыто, клиент полученные данные обработать не сможет.

В том и фишка веб сокетов, если ты не понял 8) иначе как ты представляешь себе «сервер» _послыает_ клиенту события, при том что соединение с клиентом сервер иницировать не может 8)

_________

//wfrr

Этот костыль и называется comet. И это никак не постоянное соединение, а постоянное дергание сервера и потоки кучи лишних данных.

тыб хотябы википедию читал http://ru.wikipedia.org/wiki/Comet

_________

//wfrr

Соединение, естественно, инициирует клиент. Сервер открывает вебсокет, который не закрывается вплоть до того, пока клиент не скажет «чаво-какаво»!

Ты о веб-технологиях только в вики читаешь?

Вот я и почитал. Только что. Так что не надо обзывать comet асинхронным постоянным соединением.

не открывает сервер ни чего,все болтает на 80 порту в тойже tcp сессии.

_________

//wfrr

А где же еще? Гугл + википедия.

Можно подумать, ты информацию о свежих технологиях каким-то другим способом получаешь =)

Википедию ненадо распечатывать и курить, ее читать надо.

_________

//wfrr

>информацию о свежих технологиях каким-то другим способом получаешь =)

я их придумываю

_________

//wfrr

Я имею в виду следующую схему: клиент получает адрес ws://траляля/блаблабла, открывает вебсокет по этому адресу, а на стороне сервера уже подготовленный CGI слушает.

Все элементарно. В теории. А как сделать - не понятно.

А это вообще не соединение, это принцип, позволяющий отправлять клиенту данные по запросу сервера.
Это не поллинг с интервалом.
Преимущества - работает даже в IE, работает через любые прокси, бесплатная устойчивость к потери связи.

Огромная просьба не флудить!

Мне не нужны эти квази-асинхронные соединения, работающие только на мегабитных сетях! Мне нужно реальное асинхронное соединение, то бишь вебсокет.

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

Так ты для себя пишешь?

Хочу улучшить веб-морду для работы с железом. В планах «посадить» на это спектрограф (и, может быть, метровый телескоп).

Ну хорошо, для потоковых данных комет не подходит.

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

Очень прошу сначала почитать то, что написано в самом верху, т.е. в теле темы.

Какой пых, какой питон?

> Очень прошу сначала почитать то, что написано в самом верху, т.е. в теле темы.

А, вот ты о чём. Как что? Берёшь доку к Апачу, смотришь как от него принимать соединения и как отдавать результат. Или в исходниках того же mod_php5 покопайся, посмотри как это происходит.

> как от него принимать соединения

В смысле, инициализированные клиентом. Он же их в соответствующие модули перенаправляет, которые и обрабатывают всё.

Было бы такое желание и пару месяцев отпуска, я бы здесь эту тему не поднимал :)

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

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

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

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

Изначально, когда я только узнал о вебсокетах, я думал, что достаточно будет создать сокет, как-то сообщить об этом апачу, а дальше не париться...

А оказывается, не все так легко...

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

Да без проблем его можно держать постоянно открытым. Но функции «рукопожатия» и прочую подноготную должен реализовать апач, а мой «демон» - лишь слушать сокет, да выплевывать в него данные.

но почему апач??????????777777 апач это прости атавизм, нормальные люди давно его не используют, почему тогда не виндовс или мсдос?? я все понимаю но других сравнений в голову не приходит. а раз и должен то пусть реализует модулем вот и все, но зачем по запросу какой-то модуль подключать а затем отключать причем вообще не ясно какой (если я правильно понимаю логику твоих мыслей).

но почему апач?

Nginx мне не нравится. Дохловатый какой-то.

нормальные люди давно его не используют

Ога =)

зачем по запросу какой-то модуль подключать а затем отключать причем вообще не ясно какой

Я уже все разъяснил: модуль апача (который уже есть) занимается обработкой установки соединения через вебсокеты. Но я не хочу каждый управляющий процесс делать модулем апача. А хочу, чтобы они работали в качестве демонов, общаясь с клиентом посредством передачи данных через какой-нибудь сокет, работу которого и будет обеспечивать апач.