web sockets, реализация на стороне сервера

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

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

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

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

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

_________

//wfrr

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

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

_________

//wfrr

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

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

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

_________

//wfrr

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

_________

//wfrr

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ога =)

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

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

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

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

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

в голову приходит только одна мысль, тебе хочется что бы ВСЕМ ЧТО ВЕБ РУЛИЛ АПАЧ, но это дружок уже АПАЧ ГОЛОВНОГО МОЗГА

ты часто видел что бы апач запускал демонов? честно?

У меня он этим как раз и занимается (клиент подключается, проходит аутентификацию, запускает демона, затем отправляет запросы на состояние и изменение параметров, а демон работает, пока его не отключат).

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

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

тебе хочется что бы ВСЕМ ЧТО ВЕБ РУЛИЛ АПАЧ, но это дружок уже АПАЧ ГОЛОВНОГО МОЗГА

Нет, дружок, это рациональное разделение обязанностей. Зачем мне писать свой собственный веб-сервер, если есть апач?

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

Хотя нет. Все равно бы апачем пользовался: у нас канал наружу около 50-100кбит/с. Так что, апач тормозить не будет :)

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

Можно подумать, что-то другое в этом случае тормозить не будет :)

засядут на них, ничего не делая, в ожидании таймаута,

короткий таймаут и всё.

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

Нжинкс не будет, ну, по крайней мере, не на таком малом количестве коннектов, как апач - у апача пул, что заставляет тех, кто последний, ждать своей очереди, пока те, кто первые, заняли весь пул апача. У нжинкса же лимит - грубо объем оперативы под открытые сокеты (или лимит открытых сокетов в ядре). Лайти тоже без пула работает. accf_http.ko тоже позволяет предотвратить влияние этого бага на апачах, но это оффтопик.

Короткий это сколько? 500? 250? 1000? Есть гарантия, что браузер всегда успеет доставить запрос до сервера в пределах таймаута?

> Есть гарантия, что браузер всегда успеет доставить запрос до сервера в пределах таймаута?

короткий - это пару минут

для highload, в настройках аккаунта выставлять скорость соединения, как на торрентах

плюс минимальные системные требования, latency не более чем. У кого более - отправляются менять провайдера.