Двусторонний обмен в одном HTTP соединении.

WebSockets

В настоящее время в W3C осуществляется стандартизация API Web Sockets.

Учитывая, что у меня не браузер, а штуковина юзающая Apache HttpComponents то можно делать более стандартные вещи, на шаманстве с асинхронным сервером и transfer-encoding chunked.

В этом меня смущает, что слишком много костылей выходит.

К сожалению, это единственное, что мне извесно, что позволяет коммуникацию server->client.

Само по себе оно конечно дикий костыль, т.к. http никогда под это не был задуман. Но всё же, под твоё ТЗ, вариантов, кроме этого будет скорей всего очень не много.

Альтернативой был был постоянный poll, что при малом кол-ве клиентов, может быть применим.

делается костыль под названием: http comet

суть следуюшая:

1. клиент может — в любой момент запросить какое-то действие у сервера. передать серверу данные. (через XMLHttpRequest, без «зависания» соединения)

2. клиент может в любой момент — запрость КОЛИЧЕСТВО, уведомлений, которые сервер подготовил для клиента (именно количество а НЕ само соделжимое уведомлений! это важно!). (через XMLHttpRequest, с искусственным «зависанием» соединения)

3. клиент может запросить содержимое уведомлений от сервера, заранее зная какое именно-количество умедомлений нужно запросить. (через XMLHttpRequest, без «зависания» соединения)

----------------------------------------

операция «2» отличается от операции «3» — тем что во время операции «3» — происходит «быстрая» операция.

а во время операции «2» — сервер оставлет соединение в «зависнутом состоянии» на какое-то (неопределённое) время.

часто задаваемый вопросы:

вопрос: почему мы не можем в операции «2» сразы выдать клиенту нужные данные?.. зачем именно запрашивать КОЛИЧЕСТВО уведомление, а не само содержимое отведомлений?

ответ: потому что операция «2» может прерваться в любой НЕОЖИДАННЫЙ момент как со стороны клиента так и со стороны сервера, и поэтому на стороне сервера — нет надёжного способа узнать получил ли клиент данные или не получил (клиент мог потерять данные за милисекунду до начала разрыва).

операция «2» — не является надёжной, а операция «3» является надёжной.

дополнение:

в каждый момент времени — должна произвходится только одна операция.

если не производится ни операция «1» ни операция «3» — то значит по циклу — должна производиться операция «2» (которая большую часть времени — ДОЛЖНА быть в «зависнутом» состоянии.. а не в состоянии частого переподключения).

если клиент производит операцию «2», но ему вдруг стало необходимо произвести операцию «1» — то перед тем как начать «1» — нужно отменить операцию «2» (прервать «зависание» со стороны клиента).

стоит отметить, что по сути — операция «3» является всего лишь частным случаем операции «1». :)

Если бы был GET, то подошел бы Keep-Alive вроде бы.

через long polling, ~ делаешь отдно соединение с большим таймаутом и ждёшь пока сервер чего-нибудь захочет в него записать.

Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.

А операции 1 и 3 в общем случае не обеспечивают доставку. Хотя тут зависит от конфигурации сервиса.

Server sent events?

Так это же традиционная схема работы http, запрос-ответ? HTTP keep-alive поддерживается ну почти всеми.

Не осознал вопрос. Да, long-polling самое рабочее решение на сегодня.

Проблема потери событий решается через set-cookie и удаление событий когда от клиента придет новый POST с установленной кукой.

ну можно и так. :)

в этом случае — реализация слегка упрощается на клиенте, и слегка усложняется на сервере (уникальный идентификатор для каждого из состояний — теперь должен отслеживаться на сервере. а в моей схеме — сервер не должен отслеживать уникальные идентификаторы состояния).

по эффективности — примерно тоже самое (чуть-чуть экономнее) — то есть: необходимо 2 запроса на каждую операцию уведомления «server->client» (ведь в случае с cookie сервер не может считать что передача «server->client» прошла успешно до тех пор пока client не пришлёт верный cookie в следующем запросе. то есть за 1 запрос передача «server->client» не произойдёт с точки зрения server, ведь доказательства успешности придут только в следующем запросе от клиента).

впрочем ценой такого усложнения — появляется кой-какая маленькая экономия.. (не могу это не отметить :))

------------------

при этом (в схеме с cookie) мне стоит надеется что web-браузер корректно (атомарно?) обрабатывает ситуацию — когда server успел прислать cookie о НЕ успел прислать body всего ответа (случился разрыв).. в этом случае web-браузер должен НЕ-применять cookie, а он точно это сделает?

У меня один вопрос - зачем ???

можно делать более стандартные вещи, на шаманстве с асинхронным сервером и transfer-encoding chunked

это, наверное, самый бескостыльный способ (для HTTP). оберни в свое двустороннее API, и дальше пользуй без костылей

Т.е. ты про вебсокеты не слыхал, да?