Клиент отправляет серверу HTTP запрос, например, методом GET. Проходит 5 сек. - ни ответа ни эксепшена (очевидно, что таймаут HTTP клиента больше 5 сек.). Имеет ли смысл убить соединение и повторить запрос?

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

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

Получается, что надо довериться HTTP клиенту и убивать соединение только при выбросе ексепшена, которым соединение дает знать, что оно исчерпала все попытки доставить сообщение серверу. Это можно признать разумным, если быть уверенным, что все остальные ситуации, кроме ожидания в очереди, явно заканчиваются исключением. Так ли это?

Некоторые HTTP клиенты ( но не все ) дают возможность менять таймаут соединения. В свете вышесказанного получается, что это не всегда на пользу. Таймаут не имеет смысла ставить меньше, чем типовое время задержки у провайдера (прокси сервера). Это только участит реконнекты и увеличит бесполезный траффик. В идеале таймаут клиента должен быть согласован с возможностями провайдера, а это практически невозможно в интернете, поэтому используется таймаут по умолчанию и он довольно большой.

Все это я нафантазировал решая проблему устойчивости HTTP соединения и, возможно, это не соответствует действительности. Было бы интересно узнать ваши мнения.

 

Вообще, нет такой проблемы, как устойчивость http соединения. http изначально разрабатывался как запрос-ответ протокол, т.е. ни каких поддерживающих устойчивую связь механизмов тут нету. Есть только механизм сессий, который предоставляет вебконтейнер, который работает через т.н. SID, в java он называется jsessionid, стандартно может передаваться по ссылке либо кукисом. Проблематикой доставки запроса от клиента серверу тоже не стоит заморачиваться, прокси и провайдера и промежуточные могут работать с кешем, а могут и без него, при чем кеш может оказаться разный, в том числе и на очередь пакетов от сендера, может вообще оказаться так, что статический контент будет браться только из кеша прокси, в этом случае запрос вообще не дойдет до сервака. Имхо, эти мысли все от лукавого  На то он и тонкий клиент, чтобы вопросами транспортировки данных сильно не заморачиваться...

Это сообщение отредактировал(а) y3u - 9.10.2006, 22:11

Вы совершенно правы, выражение "устойчивость http соединения" не совсем удачно и не совсем верно отражает мой вопрос. Уточню его : Имеет ли смысл повторить http запрос, или надо ждать завершения уже посланного сколь угодно долго? 

Предположим, что это ситуация, когда клиентское приложение отправляет на сервер свое локальное время каждые 5 секунд и получает простое подтверждение сервера в виде OK. Запрос всегда оригинальный из-за наличия в списке параметров GET-запроса текущего времени. 

   

Это сообщение отредактировал(а) COVD - 9.10.2006, 22:35

ну во-первых, если мы говорим про тонкий клиент, то точно ждать не стоит  При программировании под тонкого клиента, мы вообще должы подходить к происходящему с точки зрения сервера...
Можно самостоятельно проконтролировать в подмепленном на нужный контекст фильтрике поведение сервера, скажем, в приведенном примере, разбирать запрос, доставать сессию, смотреть последнее время, если 5 секунд не превышено, то возвращать SC_OK, если превышен, то, скажем, что-то писать в респонз с нужным контент тайпом... 

Через те же 5 секунд, можно послать HTTP запрос, ну например для проверки последней даты обновления. Ответ будет получен без пакета данных, таким образом сэкономишь трафик. Ну а если есть ответ от сервера, то теперь можно повторить оригинальный запрос.

Мы, похоже, каждый о своем. 



Сервер ожидает получать каждые 5 секунд сообщение от каждого клиента. Вдруг группа клиентов, сидящих на одном IP за корпоративным файерволом перестает что-то присылать - пауза 1 минута, 2 минуты, потом приходит от них залп сообщений. Все потому, очевидно, что их корпоративный прокси по какой-то причине был перегружен.

Собственно, вопрос, как себя должно вести клиентское приложение в период, когда оно не может достучаться до сервера? Ждать пока имплементация соединения выбросит исключение или придет ответ сервера. И не делать повторных попыток. Наверное, так.

Это сообщение отредактировал(а) COVD - 9.10.2006, 23:45

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

Я - про java.net.URLConnection   

Нашел ответ на свой вопрос. Возможно, я его плохо сформулировал, потому что не понимал сути проблемы. Ситуация следующая. Клиентское приложение выходит в интернет через прокси. Клиентское приложение периодически посылает на сервер HTTP запросы. 

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

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

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

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