Здравствуйте, netch80, Вы писали:

N>Я не столь пессимистичен здесь, как Cyberax — но ты где-то реально видел реализацию, которая бы способна была перенести диалог на хост с другим IP? (Да, я знаю, что можно в h_Route, h_Record-Route, h_Via писать имена, но опять же вопрос в конкретных реализациях.) А вариант, где нельзя сохранить диалог потому что нода упала — меня не интересует. А с транзакциями — ещё хуже — потому что их минимум в 2 раза больше, а при хоть каком-то signaling keepalive — не в 2 раза, а может быть и в десятки. А (повторюсь) отказ одной транзакции рушит весь диалог, потому что так по RFC3261 положено.

Эта реализация у нас уже работает. Применяется подход с virtual IP — который описан в документе, который ты назвал общим трепом.
Для случая простого SIP Proxy — это вообще не проблема, он ничего не помнит даже о текущей о транзакции. Для stateful proxy — надо реплицировать состояние транзакции между серверами — это уже задача прикладной логики и ни разу не фокус. Пример stateful proxy — это forking proxy, которая звонит тебе одновременно на несколько телефонов, пытаясь тебя найти. Для call stateful proxy — проблема полностью аналогична Web Application Server.

Причем, если тебе реально не требуется stateful и call stateful proxy, и ты можешь обойтись простым proxy (что более чем достаточно для обычного PBX) — то тебе даже состояние не надо реплицировать по кластеру.

N>"on the same host" — это что, для варианта, когда берутся 2-3 разных блока адресов, серверу даётся адрес из каждого из них и предполагается, что при обрыве раутинга на один из них другой поможет? Ну так для этого вообще-то традиционные раутинговые протоколы есть (типа OSPF или BGP). Реальный failover надо искать в тех случаях, когда это _разные_ хосты.

Мы применяем virtual IP. Нам хватает.

N>Ну и какой уровень надёжности тебе реально нужен? Да, сессия может жить сутками и неделями (как та в rsdn где я сейчас не ввожу пароль), а звонок — например, в среднем 5 минут. Но для реальной наджёности тебе всё равно надо рассчитывать, что звонок живёт час. А за час ой сколько всяого может произойти.

Для реальной надежности я могу дать клиенту отказ в продвинутом сервисе. Мне главное, чтобы а) это остальных клиентов не затронуло, и б) для этого клиента работал базовый сервис. Откинулся сервер — порвались его сессии, однако фэловер телефонов прошел — люди перезвонят, и все будет в порядке. Это вполне адекватная отказоустойчивость — сервер не каждый день ломается. А при программном сбое — последствия этого сбоя затронут только того UA, кто вызвал сбой.

G>>А в простом случае — тебя для SIP хватит stateless серверов, которыми являются proxy и stateful proxy. Состояние длительное время хранится ТОЛЬКО в случае B2BUA и call stateful proxy — но это никак не отличается от случая Web App Server.

N>Ещё раз: если транзакция началась и сорвалась — диалог гибнет весь, потому что одна из сторон получает 408 или его аналог (внутренний таймаут), а ответ второй стороны может не дойти и поэтому суммарное состояние становится некорректным (расхождение между мнениями про, например, SDP). Поэтому писать, как ты пишешь,

stateless серверов, которыми являются proxy и stateful proxy

— некорректно. Даже если в момент гибели ноды транзакцию проходили 0.1% диалогов — эти 0.1% диалогов погибнут. Именно в этом проблема такой системы для прокси.

Корректно вполне. Виртуальные IP, и нет проблем. Умерла нода — ее IP мигрировал на соседний кластер. А если что там через сервер проходило — ничего страшного, SIP рассчитан на работу поверх UDP и потеря одного пакета ничего не означает.

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

Вообще рассуждать о том насколько отказоустойчив SIP абстрактно, вне контекста приложений — довольно странное занятие.

N>Ну и мне всё-таки принципиальна специфика B2BUA. А там — ты тоже подтверждаешь, что состояние хранится длительное время и с ним надо обращаться адекватно.

Что ты пишешь такое, что тебе принципиальна семантика B2BUA, и что тебе мешает воспользоваться virtual IP и реплицировать состояние на кластере — как это делают в веб? Медия у тебя как идет? Тоже через сервер? Короче, опиши приложение.

G>>Что до разделения состояния корзины между серверами, так HTTP тут не при чем. Он никак не регламентирует такие фокусы прикладной логики — хочешь делай, хочешь нет. Я точно так же могу зашарить и состояние call stateful proxy, и применить виртуальные IP адреса, как делается и в случае веб иногда. И все, никаких проблем.

N>Ну кроме производительности и разнообразных race conditions типа "узел 1 запомнил состояние, но не успел передать на узел 2, а на узел 2 пришла следующая транзакция в диалоге".

1) Производительность сильно не просядет. SIP-сигнализация — не такая уж быстрая и требовательная к пропускной способности штука.
2) Не будет такого race condition. Не пошлет UA следующую транзакцию в диалоге, не дождавшись завершения предыдущей, а ведь ты не будешь завершать предыдущую транзакцию не отреплицировав состояние? Ну, если не вредитель конечно?

Вообще, странные вы, парни, проблемы находите. Эти проблемы ровным счетом ничем не отличаются от кластеров веба. Просто та же фигня, один в один.

Здравствуйте, PaulMinelly, Вы писали:

S>>На всякий случай напомню, что в "каждом сервере" вообще нет никакой поддержки глаголов, кроме GET.
PM>А что за сервер такой в котором POST нет?
Рукописный под раздачу чегонибудь необычного.

Здравствуйте, Gaperton, Вы писали:

N>>Ну кроме производительности и разнообразных race conditions типа "узел 1 запомнил состояние, но не успел передать на узел 2, а на узел 2 пришла следующая транзакция в диалоге".

G>1) Производительность сильно не просядет. SIP-сигнализация — не такая уж быстрая и требовательная к пропускной способности штука.
G>2) Не будет такого race condition. Не пошлет UA следующую транзакцию в диалоге, не дождавшись завершения предыдущей, а ведь ты не будешь завершать предыдущую транзакцию не отреплицировав состояние? Ну, если не вредитель конечно?

Ну, в таком варианте — да, логично. Сразу почему-то не подумал.

G>Вообще, странные вы, парни, проблемы находите. Эти проблемы ровным счетом ничем не отличаются от кластеров веба. Просто та же фигня, один в один.

Я с вебом так плотно не работал.

N>>"on the same host" — это что, для варианта, когда берутся 2-3 разных блока адресов, серверу даётся адрес из каждого из них и предполагается, что при обрыве раутинга на один из них другой поможет? Ну так для этого вообще-то традиционные раутинговые протоколы есть (типа OSPF или BGP). Реальный failover надо искать в тех случаях, когда это _разные_ хосты.
G>Мы применяем virtual IP. Нам хватает.

С именами может быть проще (протокол требует, чтобы транзакция шла с одним IP, а вот диалог может связываться с любым).

N>>Ну и какой уровень надёжности тебе реально нужен? Да, сессия может жить сутками и неделями (как та в rsdn где я сейчас не ввожу пароль), а звонок — например, в среднем 5 минут. Но для реальной наджёности тебе всё равно надо рассчитывать, что звонок живёт час. А за час ой сколько всяого может произойти.
G>Для реальной надежности я могу дать клиенту отказ в продвинутом сервисе. Мне главное, чтобы а) это остальных клиентов не затронуло, и б) для этого клиента работал базовый сервис. Откинулся сервер — порвались его сессии, однако фэловер телефонов прошел — люди перезвонят, и все будет в порядке. Это вполне адекватная отказоустойчивость — сервер не каждый день ломается. А при программном сбое — последствия этого сбоя затронут только того UA, кто вызвал сбой.

Ну такой уровень и у нас сейчас есть. Но хочется большего.

G>К тому же, я не понимаю что плохого в том, что умрут диалоги в случае аппаратного сбоя. Это полная херня, пусть умирают. Перезвонят, не обломятся, не так часто аппаратные сбои происходят.

;)))

N>>Ну и мне всё-таки принципиальна специфика B2BUA. А там — ты тоже подтверждаешь, что состояние хранится длительное время и с ним надо обращаться адекватно.
G>Что ты пишешь такое, что тебе принципиальна семантика B2BUA, и что тебе мешает воспользоваться virtual IP и реплицировать состояние на кластере — как это делают в веб? Медия у тебя как идет? Тоже через сервер? Короче, опиши приложение.

Софтсвич с B2BUA посредине. "Медия" может и напрямую идти, и через сервер — в зависимости от настроек. Virtual IP мне не нравится. С именем будет удобнее.

Здравствуйте, PaulMinelly, Вы писали:

S>>На всякий случай напомню, что в "каждом сервере" вообще нет никакой поддержки глаголов, кроме GET.

PM>А что за сервер такой в котором POST нет?
Переформулируем вопрос — в каком есть? Из известных мне ни один не в состоянии самостоятельно обработать POST без обращения к пользовательским расширениям.

На всякий случай напомню, что штатный HTTP сервер комплектуется исключительно отдавалкой статических файлов по GET.
Всё остальное — это расширения.

Здравствуйте, PaulMinelly, Вы писали:

PM>Дело то не совсем в том как оно сейчас работает. А в том что нет докачки (upload). Закачивал 100 меговый файл, связь оборвалась. Ни в одном браузере докачки нет. Даже сделай я эту фичу, например загрузка с 50 байта по 900 — ниодин сервер ее поддерживать не будет. Почему?

Потому что это мало кого интересовало.
Вообще закачка файлов в браузерах реализована из рук вон плохо — даже до уровня требований HTML 3.2 ни один известный мне браузер не дошел.

Поэтому тебя это всё волновать особенно не будет — если ты захочешь решить эту проблему, то есть стандартный путь:
1. Пишешь серверный скрипт, который умеет принимать частичную закачку.
2. Пишешь клиентский контрол на Flash или Silverlight, который умеет пользоваться твоим расширением
3. Пользователи счастливы.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, PaulMinelly, Вы писали:

S>>>На всякий случай напомню, что в "каждом сервере" вообще нет никакой поддержки глаголов, кроме GET.

PM>>А что за сервер такой в котором POST нет?
S>Переформулируем вопрос — в каком есть? Из известных мне ни один не в состоянии самостоятельно обработать POST без обращения к пользовательским расширениям.

В Апаче POST принимается расширением?

Здравствуйте, PaulMinelly, Вы писали:

PM>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, PaulMinelly, Вы писали:

S>>>>На всякий случай напомню, что в "каждом сервере" вообще нет никакой поддержки глаголов, кроме GET.

PM>>>А что за сервер такой в котором POST нет?
S>>Переформулируем вопрос — в каком есть? Из известных мне ни один не в состоянии самостоятельно обработать POST без обращения к пользовательским расширениям.

PM>В Апаче POST принимается расширением?

А что, обрабатывается он тоже апачем? Или таки перенаправляется пользовательскому расширению?

Здравствуйте, PaulMinelly, Вы писали:
PM>В Апаче POST принимается расширением?
RTFM: http://www.apacheweek.com/features/put.

There is some confusion about whether Apache supports the PUT method. In fact, Apache handles PUT exactly like it handles the POST method. That is, it supports it, but in order for it to do anything useful you need to supply a suitable CGI program. This is on contrast to the GET method, which Apache supports internally by sending back files or SSI documents.

На всякий случай перевожу главную фразу:

То есть, он [Апач] поддерживает их [GET и POST], но чтобы он мог сделать что-нибудь полезное, ты должен предоставить подходящую CGI-программу

А вообще, приличные веб сервера в таких случаях отдают не 200 ok, а 405 Method not allowed (кстати, первый попавшийся мне под руку Апач так и делает для PUT)

PaulMinelly wrote:

> В Апаче POST принимается расширением?
Ещё можно добавить, что глагол может быть любым, можешь свой глагол придумать (webdav использует кучу разных глаголов, скажем COPY, MOVE, LOCK, MKCOL), веб-сервер же понимает только GET, остальное тупо спихивает пользовательским скриптам/модулям. Типичный веб-браузер умеет только GET и POST. Но это не ограничения протокола HTTP.

>> В Апаче POST принимается расширением?
.>Ещё можно добавить, что глагол может быть любым, можешь свой глагол придумать (webdav использует кучу разных глаголов, скажем COPY, MOVE, LOCK, MKCOL), веб-сервер же понимает только GET, остальное тупо спихивает пользовательским скриптам/модулям. Типичный веб-браузер умеет только GET и POST. Но это не ограничения протокола HTTP.

Из Яваскрипта уже можно и PUT и DELETE, если мне память не изменяет

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, PaulMinelly, Вы писали:
PM>>В Апаче POST принимается расширением?
S>RTFM: http://www.apacheweek.com/features/put.
S>

There is some confusion about whether Apache supports the PUT method. In fact, Apache handles PUT exactly like it handles the POST method. That is, it supports it, but in order for it to do anything useful you need to supply a suitable CGI program. This is on contrast to the GET method, which Apache supports internally by sending back files or SSI documents.

S>На всякий случай перевожу главную фразу:
S>

То есть, он [Апач] поддерживает их [GET и POST], но чтобы он мог сделать что-нибудь полезное, ты должен предоставить подходящую CGI-программу

S>А вообще, приличные веб сервера в таких случаях отдают не 200 ok, а 405 Method not allowed (кстати, первый попавшийся мне под руку Апач так и делает для PUT)

Что-то ничего не понял. Т.е. вот допустим мы послали POST. Он пришел на сервер и далее чтобы что-то сделать с этим POSTом надо писать php скрипт который допустим будет сохранять POST в базу данных. Ну это и так понятно что Апач без php-скрипта (который кстати может И НЕ БЫТЬ CGI, не одним же CGI-ем жив обмен между серваком и интерпреатором), так вот понятно что Апач без php-скрипта не сохранит этот POST в базу. Так о чем разговор? Конечно прога нужна. А чтобы сохранить запрос GET в базу — что прога не нужна? Точно так же нужна, так о каких тонких материях спор?

Здравствуйте, PaulMinelly, Вы писали:

PM>Что-то ничего не понял. Т.е. вот допустим мы послали POST. Он пришел на сервер и далее чтобы что-то сделать с этим POSTом надо писать php скрипт который допустим будет сохранять POST в базу данных. Ну это и так понятно что Апач без php-скрипта (который кстати может И НЕ БЫТЬ CGI, не одним же CGI-ем жив обмен между серваком и интерпреатором),
Совершенно верно.
PM> так вот понятно что Апач без php-скрипта не сохранит этот POST в базу. Так о чем разговор?
PM>Конечно прога нужна. А чтобы сохранить запрос GET в базу — что прога не нужна?
Нет, не нужна. GET апач обработает безо всякой проги. Записывать GET в базу не нужно. Читайте RTFM.
PM>Точно так же нужна, так о каких тонких материях спор?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, PaulMinelly, Вы писали:

PM>>Что-то ничего не понял. Т.е. вот допустим мы послали POST. Он пришел на сервер и далее чтобы что-то сделать с этим POSTом надо писать php скрипт который допустим будет сохранять POST в базу данных. Ну это и так понятно что Апач без php-скрипта (который кстати может И НЕ БЫТЬ CGI, не одним же CGI-ем жив обмен между серваком и интерпреатором),
S>Совершенно верно.
PM>> так вот понятно что Апач без php-скрипта не сохранит этот POST в базу. Так о чем разговор?
PM>>Конечно прога нужна. А чтобы сохранить запрос GET в базу — что прога не нужна?
S>Нет, не нужна. GET апач обработает безо всякой проги. Записывать GET в базу не нужно. Читайте RTFM.

А что это не нужно? Вот например поисковый запрос в гугле — это урл со всякими параметрами оформленный методом GET с главной страницы. Я беру этот урл и отдаю другу. Друг просто открывает страницу и видит результаты поиска. Удобно. Теперь вы хотите сказать что гугл не должен записывать в базу данные GET запроса, а всегда оформлять его как POST? Причем не потому что это удобно, а потому это написано не понятно почему в RTMF? Кстати где этот rtfm интересно посмотреть как это сформулировано — как пожелание скромного ученого или как прямо запрет на сохранение GET запроса в базу.

Здравствуйте, PaulMinelly, Вы писали:
PM>А что это не нужно? Вот например поисковый запрос в гугле — это урл со всякими параметрами оформленный методом GET с главной страницы. Я беру этот урл и отдаю другу. Друг просто открывает страницу и видит результаты поиска. Удобно.
Ну, такой поддержки GET конечно же в Апаче нет. Тем не менее, для статического файлового контента семантика GET хорошо определена и встроена в сервер.
PM>Теперь вы хотите сказать что гугл не должен записывать в базу данные GET запроса, а всегда оформлять его как POST?
Это два не связанных между собой утверждения.
PM> Причем не потому что это удобно, а потому это написано не понятно почему в RTMF? Кстати где этот rtfm интересно посмотреть как это сформулировано — как пожелание скромного ученого или как прямо запрет на сохранение GET запроса в базу.
Читайте RFC 2616. Особенно раздел 9.1.1. Из него, в принципе, понятно, почему умение обрабатывать GET и HEAD встроено в современные HTTP сервера, а PUT, POST и DELETE — не очень.

M>Из Яваскрипта уже можно и PUT и DELETE, если мне память не изменяет
А почему только PUT и DELETE? Разве XMLHTTP компонент накладывает ограничения на глаголы? Глянул мельком в MSDN — вроде как ограничений нет...

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, PaulMinelly, Вы писали:
PM>>А что это не нужно? Вот например поисковый запрос в гугле — это урл со всякими параметрами оформленный методом GET с главной страницы. Я беру этот урл и отдаю другу. Друг просто открывает страницу и видит результаты поиска. Удобно.
S>Ну, такой поддержки GET конечно же в Апаче нет. Тем не менее, для статического файлового контента семантика GET хорошо определена и встроена в сервер.

Клево, то поддержка ГЕТ есть, то нет. Ужосы.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Andrei N.Sobchuck, Вы писали:

C>>>Я лично писал штук пять парсеров для HTTP. Вот недавно как раз ещё один закончил — меня не удовлетворило как стандартный работал с keep-alive'ом.
ANS>>Стандартный кто?
C>Стандартный java.io.URLConnection

Appache Commons.HttpClient?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vb-develop, Вы писали:
VD>>Какие, например? (так для общего развития)
S>Например искать по слову REST.

И как REST соотносится с веб-сервисами? ИМХО, это понятия из разной области совершенно. Большинство фич HTTP веб-сервисы не используют, ибо эти фичи к задаче транспортировки сообщений не применимы по принципиальным соображениям.

Здравствуйте, Sinclair, Вы писали:

S>2. Ну, вот мне почему-то разбор бинарного ASN.1 не кажется намного проще парсинга хидеров HTTP реквеста.

Проще гораздо, т.к. ты компилятору ASN.1 скармливаешь описание формата, на выходе получаешь готовый парсер. Это что-то вроде регекспов для текста, только гораздо мощнее (значительно больший класс грамматик захватывает).

Здравствуйте, Gaperton, Вы писали:


G>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.

Угу, SIP хорош для установления связи. Хорош потому, что допускает практически произвольное расширение. Собственно, как и XMMP. Но у того и другого очень слабая связанность с самой связью, т.е. с целью их существования, т.к. по TCP стороны могли запросто связаться о начале медиа-сеанса, а сам медиа-сеанс через NAT может и не пойти, не взирая на все STUN-ы в округе.

--------------
А вообще, затронули практически корень проблемы. Если зрить в этот самый корень, то TCP плохо подходит под транспорт инфраструктуры обмена сообщениями (вот такое богохульство). Мы в конечном итоге выбрали IAX2, который использует только UDP. Ведь что мы имеем и что требуется в системах типа запроc-ответ:
— асинхронность, произвольный порядок обработки сообщений.
— целостность нужна только на уровне пакета.
— подтверждать пакеты вовсе не требуется в том же порядке, в каком они к нам приходят.
— еще много мелочей, характерных для протоколов, которым НЕ ТРЕБУЕТСЯ установление связи (сеанса)

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

Относительно SIP вообще смешно получилось. Session Initiation Protocol, типа производит установление сессии. Для тех кто не в курсе, скажу, что там в 99.99% случаев происходит обмен парой сообщений длиной по сотне байт каждое с целью установления RTP-сессии (RTP живёт поверх UDP, опять же). Где здравый смысл? Зачем устанавливать TCP-сессию перед тем как начать процесс установки UDP-based сессии?