Нужен совет

← →
Ega23 © (2008-04-10 13:00) [0]

Архитектура: тонкий клиент -> Веб-Сервер -> Сервер приложений -> БД
В качестве Веб-Сервера - Апач 2.2 (платформа пока неизвестна, возможно и win и *nix).
Общение между Веб-Сервером и Сервером приложений идёт по некой надстройке над TCP.
Основная проблема - постоянная поддержка соединения во время работы клиента. Т.е. клиент начал работу - открылось соединение, клиент закончил работу - соединение закрылось.
Пока виден один вариант - FastCGI. Вроде как это дело, в отличие от обычного CGI, инициализирует процесс один раз. Проблема - не везде работает (насколько я понял из описания).
Вроде есть второй вариант решения - написание собственного модуля для Apache.
Собственно вопрос: если кто с такими делами сталкивался - что посоветуете? В какую сторону копать? Может ещё какие варианты есть?

← →
Reindeer Moss Eater © (2008-04-10 13:11) [1]

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

← →
user_ (2008-04-10 13:28) [2]

Несовсем понятно что я вляется клиентом, и для каких целе необходим данный подход ?

← →
Reindeer Moss Eater © (2008-04-10 13:35) [3]

без разницы что там является клиентом. проблема в том, что используемый протокол (http) не ориентирован на постоянное соединение. И поэтому нельзя привязать соединение с БД в сервере приложений с сессией клиента.

← →
tesseract © (2008-04-10 13:43) [4]

> И поэтому нельзя привязать соединение с БД в сервере приложений
> с сессией клиента.

mod_perl? Вроде по документации может организовывать постоянное соединение с базой.

> Веб-Сервера - Апач 2.2 (платформа пока неизвестна, возможно
> и win и *nix).

TomCat вроде служит для таких целей.

← →
user_ (2008-04-10 13:45) [5]

> Reindeer Moss Eater © (10.04.08 13:35) [3]

Понял

> Ega23 © (10.04.08 13:00)

тогда действительно только

> Reindeer Moss Eater © (10.04.08 13:11) [1]

акакже тогда сервер узнает когда "убить" при потере сесии ?

← →
знаток (2008-04-10 13:51) [6]

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

← →
Reindeer Moss Eater © (2008-04-10 13:52) [7]

стандартно, по таймауту, или по явному запросу клиента

← →
знаток (2008-04-10 13:52) [8]

> user_ (10.04.08 13:45) [5]
> > Reindeer Moss Eater © (10.04.08 13:11) [1]
> акакже тогда сервер узнает когда "убить" при потере сесии
> ?

Как всегда. Убивать тех, кто не обращался дольше, чем N минут.

← →
Оригинал (2008-04-10 14:14) [9]

> Пока виден один вариант - FastCGI. Вроде как это дело, в
> отличие от обычного CGI, инициализирует процесс один раз.
> Проблема - не везде работает (насколько я понял из описания).
>

На Apache WIN загружаемые библиотеки (DLL) тоже один раз загружаются.
Создаем пул соединений с базой. При необходимости можно использовать любое соединение из пула. Либо сохранять за клиентом от сессии к сессии какое-то одно.

← →
Плохиш © (2008-04-10 15:25) [10]

> Ega23 © (10.04.08 13:00)
> Основная проблема - постоянная поддержка соединения во время
> работы клиента. Т.е. клиент начал работу - открылось соединение,
> клиент закончил работу - соединение закрылось.

А смысл? При подключении клиента, генерируется идентификатор, который сохраняется в кукисах или в скрытых полях хтмл-страницы. При следующих запросах берётся этот идентификатор и определяется "хтой-то тут у нас припёрся" :-)

https соединение вроде постоянное (замечено через handycashe)

> https соединение вроде постоянное

пока не оборвется по неизвестным причинам :)
поскольку тср не гарантирует сохрнения подключения, то единственный выход предложил Reindeer Moss Eater ©
регулярное оповещение клиентом сервера, что он на связи + уничтожение сессий по таймауту

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

← →
Оригинал (2008-04-10 21:30) [14]

> Reindeer Moss Eater © (10.04.08 13:35) [3]
> без разницы что там является клиентом. проблема в том, что
> используемый протокол (http) не ориентирован на постоянное
> соединение. И поэтому нельзя привязать соединение с БД в
> сервере приложений с сессией клиента.

8 Соединения (Connections). 8.1 Постоянные соединения (Persistent Connections). 8.1.1 Цель. До постоянных соединений для запроса каждого URL устанавливалось отдельное TCP соединение, что увеличивало нагрузку на HTTP сервера и вызывало загрузку Интернета. Использование встроенных изображений и других связанных данных часто требует от клиента делать несколько запросов к одному серверу за короткий промежуток времени. Исследования проблем эффективности такого решения доступны в [30][27]; анализ и результаты реализации прототипа находятся в [26]. Постоянные HTTP соединения имеют ряд преимуществ: o Открытие и закрытие меньшего количества TCP соединений экономит время центрального процессора и память, используемую для управляющих блоков протокола TCP. o HTTP запросы и ответы может быть конвейеризованы в соединении. Конвейерная обработка позволяет клиенту делать множество запросов не ожидая ответа на каждый, следовательно, одиночное TCP соединение, использование которого намного более эффективно, теряет меньше времени. o Загрузка сети уменьшается с уменьшением числа пакетов, вызванных открытием TCP соединений, и, следовательно, дает протоколу TCP достаточное время для определения состояния загрузки сети. o HTTP может развиваться более элегантно; так как ошибки могут сообщаться без закрытия TCP соединения в качестве штрафа. Клиенты, использующие будущие версии HTTP могли бы оптимистично пробовать новые возможности, но при связи со старым сервером, повторять запрос, используя старую семантику после сообщения об ошибке. HTTP реализациям СЛЕДУЕТ реализовывать постоянные соединения. 8.1.2 Общее описание. Значительное отличие HTTP/1.1 от более ранних версий HTTP состоит в том, что постоянные соединения являются заданным по умолчанию поведением любого HTTP соединения. То есть если не обозначено иного, клиент может считать, что сервер поддержит постоянное соединение. Постоянные соединения обеспечивают механизм, согласно которому клиент и сервер могут сообщить о разрыве TCP соединения. Это сигнализируется при помощи использования поля заголовка Connection. При получении сообщения о разрыве соединения клиент НЕ ДОЛЖЕН посылать больше запросов по этому соединению. 8.1.2.1 Обсуждение (Negotiation). HTTP/1.1 сервер МОЖЕТ считать, что HTTP/1.1 клиент не предполагает поддерживать постоянное соединение, если посланный в запросе заголовок Connection содержит лексему соединения (connection-token) "close". Если сервер решает закрыть соединение немедленно после посылки ответа, то ему СЛЕДУЕТ послать заголовок Connection, который содержит лексему соединения (connection-token) "close". HTTP/1.1 клиент МОЖЕТ ожидать, что соединение останется открытым, но должен решить оставлять ли его открытым на основании того, содержит ли ответ сервера заголовок Connection с лексемой соединения "close". В случае, если клиент не хочет поддерживать соединение для последующих запросов, ему СЛЕДУЕТ послать заголовок Connection, содержащий лексему соединения "close". Если клиент или сервер посылает лексему закрытия соединения "close" в заголовке Connection, то запрос становится последним в соединении. Клиентам и серверам НЕ СЛЕДУЕТ считать, что постоянное соединение поддерживается HTTP версиями, меньшими чем 1.1, если это не указано явно. Смотрите раздел 19.7.1 с более подробной информацией о обратной совместимости с HTTP/1.0 клиентами. Чтобы соединение оставалось постоянным, все сообщения, передаваемые по нему должны иметь самоопределенную (self-defined) длину сообщения (то есть, не определяемую закрытием соединения), как описано в разделе 4.4. 8.1.2.2 Конвейерная обработка (Pipelining). Клиент, который поддерживает постоянные соединения МОЖЕТ "произвести конвейерную обработку" запросов (то есть, посылать несколько запросов не ожидая ответа на каждый). Сервер ДОЛЖЕН послать ответы на эти запросы в том же самом порядке, в каком были получены запросы. Клиенты, которые поддерживают постоянные соединения и производят конвейерную обработку немедленно после установления соединения, ДОЛЖНЫ быть готовы повторить соединение, если первая попытка конвейерной обработки дала сбой. Если клиент делает такой повтор, он НЕ ДОЛЖЕН производить конвейерную обработку прежде, чем узнает, что соединение постоянное. Клиенты ДОЛЖНЫ также быть готовы снова послать запросы, если сервер закрывает соединение перед посылкой всех соответствующих ответов.

> Речь шла о поддержке связи между веб-сервером и сервером
> приложений.

а что меняется? базовый протокол тот же, веб-сервер для сервера приложений - клиент

Нужен совет Найти похожие ветки