piplining

[Kostya Alexandrov]

Авторизация не SSL, если вы имеете ввиду авторизацию по ключу. SSL 
просто закрывает http.
Авторизация - получение session id (колбаса из ХХХ сиволов) и брожение с 
ней в качестве куки или параметра в сервлете.
Именно push. Его и городим. С таймаутами проблем нет. Если слать нечего, 
нужно слать ping. Иначе клиент не будет знать о том соединение живо или 
нет, и его какой нить роутер по дороге не пристрелил. И сделать такое 
вполне возможно :)

Как сделаю скажу точно можно или нет.

Pipelining хотелось (и выйдет) пользовать для того чтоб соединение было 
двунаправленным.

David Mzareulyan wrote:
> Hello Kostya,
>
>> Под "просто сокетом" панимается установка двунаправленного tcp
>> соединения. От китайцев спасает ssl, ну по крайей мере я в это верю :)
>
> Ага, так значит фаза авторизации у Вас всё-таки есть, причём недешёвая 
> (ssl). Тогда о чём весь этот джаз?
>
>> Про кроликов - я согласен, но альтернативы не вижу на "пока что".
>> Ngnix сейчас выступает как ssl+keep alive фронтенд для клиентов, в
>> ближайшем будущем
>> сервлеты отдающие изменеия клиенту перестанут закрывать аут и начнут
>> выталкивать
>> изменения.
>> David Mzareulyan wrote:
>>
>>> Hello Kostya,
>>>
>>>> А вот тут Вы не правы (скажу очень мягко). Это сильно зависит от
>>>> бекенда. У меня есть сессия, и мне выгодно иметь персистент
>>>> конекшен. Т.к. бекенд никогда не закончит отдавать, он будет писать
>>>> в аут до тех пор пока клиент не скажет логаут.
>>>>
>>> Эта задача, вообще говоря, не требует обязательного персистента с
>>> бэкендом. Но она да, требует некоторой доработки nginx-а. Это
>>> обсуждалось в рассылке, но, к сожалению, Игорь особого интереса к
>>> задаче не проявил.
>>>
>> А можно чуть подробнее? Пока не тестированно. Находится в глубокой
>> бете. Если бекенд "никогда" не закончит писать, то это не сработает в
>> случае фронтенда ngnix? Я только несколько дней как читаю эту конфу.
>
> Сработает, скорее всего. Если nginx не отрубит бэкенд по таймауту, 
> конечно, ну так это настраивается.
>
> А то, о чём я говорю -- это всевозможные сomet- и push-технологии, в 
> которых гораздо удобнее было бы разделить слой, поддерживающий 
> соединение с клиентом (nginx, очевидно) и слой, подающий в это 
> соединение данные (бэкенд). Но сейчас такую конструкцию сделать всё 
> равно невозможно.
>
>
>>>> Это дорго каждый раз устанавливать
>>>> соединение и т.п. С другой стороны от http тоже никак не уйдеш, есть
>>>> клиенты которые сидят за прокси, если прокси забыть то всех бы
>>>> спасли
>>>> tcp соединения... Но клиенты иногда еще посылают команды серверу. И
>>>> очень бы хотелось использовать тот же сокет, тогда на стороне
>>>> бекенда
>>>> я могу избежать авторизации.
>>> А это уже от корявости архитектуры. Не приспособлен HTTP для
>>> подобного, как не приспособлены кролики для лазанья по деревьям. И
>>> потом, что значит "тот же сокет"? Вы же сами только что о прокси
>>> говорили, за которым хоть миллиард китайцев сидеть может. И будут они
>>> все слать всё в "тот же сокет" без авторизации...
>>>
>>>> Проблемы тормозов на бекенде и решаем. Просто не хочется выставлять
>>>> прямо в инет сам бекенд. Просто страшно.
>>>>
>>>> p.s.
>>>> Я думаю господин Сысоев будет несколько обескуражен
>>>> основной задачей "как можно быстрее освободить процесс backend для
>>>> следующих запросов" :)
>>>> Andrew Sitnikov wrote:
>>>>> Hello Kostya,
>>>>>
>>>>> KA> Плохо. Даже отвратительно. Ну ладно.
>>>>>
>>>>> задача nginx как можно быстрее освободить процесс backend для
>>>>> следующих запросов, keepalive совсем
>>>>>
>>>>> этому не способствует. имхо вам надо не костыли а стороне frondend
>>>>> изобретать а решать проблему с вашим
>>>>>
>>>>> тормозным backend.
>>>>>
>
>