ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: piplining



Авторизация не 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.






 




Copyright © Lexa Software, 1996-2009.