Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>Есть ли такие компиляторы для HTTP? S>Эмн... S>Ну, обычно базовый разбор заголовков входит в обязанности HTTP-клиента.
Тогда, как мне кажется, твое противопоставление сложности парсинга не актуально, посколько обычному программисту не приходится ручками работать с ASN.1 и с HTTP-заголовками.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
S>>Ну, обычно базовый разбор заголовков входит в обязанности HTTP-клиента. E>Тогда, как мне кажется, твое противопоставление сложности парсинга не актуально, посколько обычному программисту не приходится ручками работать с ASN.1 и с HTTP-заголовками.
Я лично писал штук пять парсеров для HTTP. Вот недавно как раз ещё один закончил — меня не удовлетворило как стандартный работал с keep-alive'ом.
Здравствуйте, Cyberax, Вы писали: C>Я лично писал штук пять парсеров для HTTP. Вот недавно как раз ещё один закончил — меня не удовлетворило как стандартный работал с keep-alive'ом.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не, дескриптор не проблема, проблема в том, что ты за деревьями не видишь леса. Это как, рассуждая о тенденциях в проектировании автомобилей, обсуждать хим. процесс получения пластика для плафона освещения багажника.
Что-то не врубаюсь. Я всего лишь сказал, что возможны два формата — текстовый и бинарный. Десктопных программ, которые в нескольких форматах сохраняют, хоть пруд пруди (у того же Word их сколько ?), это вообще банальность. При чем тут деревья и лес — как-то непонятно.
Ты лучше это замечание Синклеру переадресуй, я писал там про иерархические запросы, а он меня упорно пытал — а как же там кеширование будет
Здравствуйте, netch80, Вы писали:
N>Проблема не в затратах, а в том, что это таки разный код. И глюк в релизном коде ты не сможешь поймать отладочной версией. Вот это тут таки принципиально.
Я все-таки не понимаю. Если запрос будет переводиться из текстового вида в двоичный на выходе из броузера, а потом IIS переведет его обратно в текстовый перед тем, как отдать тебе, какой-такой разный код будет в твоем приложении ?
А если и не будет такого преобразования — не надо из мух слонов делать. Word поддерживает два десятка форматов, и чтение/запись в них — это разный код. И ничего страшного. Запись и чтение файла — это 1% от того, что содержит в себе Word.
Здравствуйте, PaulMinelly, Вы писали:
PM>Клево, а поддержза возобновления _закачки_ (upload) тоже в http есть? Или надо для этого расширять каждого клиента и сервера?
А как Вы это себе представляете? Частичная закачка — это семантика файлов, а HTTP совсем не файловый (в основе) протокол.
Если сервер будет отрабатывать просто файлопомойку, то, думаю, он согласится с PUT + h_Range. Но если что-то более сложное — основная проблема будет в том, как дать серверу сигнал, что всё закачали и можно что-то делать с файлом. А это уже — уровень исполняемой логики на сервере.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, PaulMinelly, Вы писали:
PM>>Клево, а поддержза возобновления _закачки_ (upload) тоже в http есть? Или надо для этого расширять каждого клиента и сервера?
N>А как Вы это себе представляете? Частичная закачка — это семантика файлов, N>а HTTP совсем не файловый (в основе) протокол.
А как Вы это узнали? В rfc так и написано вверху "передаем только гипертекст. Ни в коем случае не передаем файлы. Поэтому будьте осторожны."
N>Если сервер будет отрабатывать просто файлопомойку, то, думаю, он согласится с PUT + h_Range. Но если что-то более сложное — основная проблема будет в том, как дать серверу сигнал, что всё закачали и можно что-то делать с файлом. А это уже — уровень исполняемой логики на сервере.
Не знаю, не знаю, по-моему это один из хреновых недочетов HTTP который исправить в его рамках нельзя.
Серверу сигнал можно не давать, а достаточно сказать объем закачиваемых данных — пусть он сам решает все пришло или нет.
Здравствуйте, PaulMinelly, Вы писали: PM>Клево, а поддержза возобновления _закачки_ (upload) тоже в http есть? Или надо для этого расширять каждого клиента и сервера?
Непонятно, что именно имеется в виду. В HTTP вообще нет понятия "upload". Есть PUT, есть POST.
В самом протоколе требования поддерживать Ranges в PUT/POST нету.
На всякий случай напомню, что в "каждом сервере" вообще нет никакой поддержки глаголов, кроме GET.
Даже для того, чтобы принимать файлы целиком, нужно этого "каждого сервера" расширять.
Характерный пример такого расширения — SVN. SVN клиент умеет передавать на SVN сервер только изменения, а не сами файлы. И всё это по протоколу HTTP.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
C>>Я лично писал штук пять парсеров для HTTP. Вот недавно как раз ещё один закончил — меня не удовлетворило как стандартный работал с keep-alive'ом. ANS>Стандартный кто?
Стандартный java.io.URLConnection
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
C>>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. G>>?! Смотри, как это делается. Несколько способов. G>>http://www.cs.columbia.edu/techreports/cucs-011-04.pdf C>Да я знаю. Костыли можно поставить кое-где.
Вообще-то на это тему есть RFC, и никаких костылей не требуется. Стандартной для SIP техникой обеспечения отказоустойчивости и рапределенности является специальное правило трактовки записей DNS SRV и NAPRT, закрепленное в специальном SIP-овском RFC.
G>>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет? C>SIP — он STATEFUL. HTTP банально баллансируется простым раскидываением запрос между backend-серверами.
SIP НЕ stateful. Там четыре уровня серверов — просто proxy, stateful proxy (хранит состояние транзакции — например INVITE — в этом смысле у тебя и HTTP stateful), call stateful proxy (хранит состяние звонка), и B2BUA (самая жесть). Первые два типа серверов формируют центральную часть сети, и они по сути stateless. На них уже можно сделать PBX. Остальные два — имеют мало отличий с Web Application Servers, стоят на переферии сети, и их можно откластеризовать на уровне сессий. В чем проблема? Не понимаю. Принципиальных отличий от веба не вижу. Покажешь?
Здравствуйте, netch80, Вы писали:
N>Настоящего failover'а там нет (при котором разделяются и используются всеми данные транзакций и диалогов), а то что есть — общий трёп на тему "в DNS можно писать более одного адреса для имени". Шарят данные регистраций — ну это сейчас любой умеет.
И вот это: The Stream Control Transmission Protocol (SCTP)
as a Transport for the Session Initiation Protocol (SIP) http://www.ietf.org/rfc/rfc4168.txt
Multihoming: An SCTP connection can be associated with multiple IP
addresses on the same host. Data is always sent over one of the
addresses, but if it becomes unreachable, data sent to one can
migrate to a different address. This improves fault tolerance;
network failures making one interface of the server unavailable do
not prevent the service from continuing to operate. SIP servers
are likely to have substantial fault tolerance requirements. It
is worth noting that, because SIP is message oriented and not
stream oriented, the existing SRV (Service Selection) procedures
defined in [5] can accomplish the same goal, even when SIP is run
over TCP. In fact, SRV records allow the 'connection' to fail
over to a separate host. Since SIP proxies can run statelessly,
failover can be accomplished without data synchronization between
the primary and its backups. Thus, the multihoming capabilities
of SCTP provide marginal benefits.
G>>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет?
N>На HTTP ты можешь между разными серверами расшарить, например, состояние корзины покупателя (которую он модифицирует каждым кликом в браузере)? Ну да, можешь, но цена абсолютно та же, что для SIP — общее состояние, его репликация... И для HTTP каждый отдельный запрос/ответ живёт короче, чем диалог в SIP.
Для HTTP при наличии серверной логики сессия живет гораздо длиннее, чем сессия SIP в случае телефонии.
А в простом случае — тебя для SIP хватит stateless серверов, которыми являются proxy и stateful proxy. Состояние длительное время хранится ТОЛЬКО в случае B2BUA и call stateful proxy — но это никак не отличается от случая Web App Server.
Что до разделения состояния корзины между серверами, так HTTP тут не при чем. Он никак не регламентирует такие фокусы прикладной логики — хочешь делай, хочешь нет. Я точно так же могу зашарить и состояние call stateful proxy, и применить виртуальные IP адреса, как делается и в случае веб иногда. И все, никаких проблем.
Здравствуйте, Gaperton, Вы писали:
C>>Да я знаю. Костыли можно поставить кое-где. G>Вообще-то на это тему есть RFC, и никаких костылей не требуется. Стандартной для SIP техникой обеспечения отказоустойчивости и рапределенности является специальное правило трактовки записей DNS SRV и NAPRT, закрепленное в специальном SIP-овском RFC.
С их помощью нельзя сделать failover для транзакций и диалогов. Поэтому идут в топку.
G>>>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет? C>>SIP — он STATEFUL. HTTP банально баллансируется простым раскидываением запрос между backend-серверами. G>SIP НЕ stateful.
Нет. Он ЯВНО stateful, так как в самом протоколе прописаны транзакции, захватывающие несколько запросов (см. со страницы 122 в rfc3261).
G>Там четыре уровня серверов — просто proxy, stateful proxy (хранит состояние транзакции — например INVITE — в этом смысле у тебя и HTTP stateful), call stateful proxy (хранит состяние звонка), и B2BUA (самая жесть). Первые два типа серверов формируют центральную часть сети, и они по сути stateless. На них уже можно сделать PBX. Остальные два — имеют мало отличий с Web Application Servers, стоят на переферии сети, и их можно откластеризовать на уровне сессий. В чем проблема? Не понимаю. Принципиальных отличий от веба не вижу. Покажешь?
Да. Покажи мне SIP-сервер, который умеет делать failover в середине транзакции. А я тебе покажу приложение, которое прозрачно делает failover для HTTP-запросов.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, netch80, Вы писали:
N>>Настоящего failover'а там нет (при котором разделяются и используются всеми данные транзакций и диалогов), а то что есть — общий трёп на тему "в DNS можно писать более одного адреса для имени". Шарят данные регистраций — ну это сейчас любой умеет.
G>RFC — это общий треп?
Нет, этот pdf — общий трёп.
G> На, почитай внимательно.
Я не столь пессимистичен здесь, как Cyberax;) — но ты где-то реально видел реализацию, которая бы способна была перенести диалог на хост с другим IP? (Да, я знаю, что можно в h_Route, h_Record-Route, h_Via писать имена, но опять же вопрос в конкретных реализациях.) А вариант, где нельзя сохранить диалог потому что нода упала — меня не интересует. А с транзакциями — ещё хуже — потому что их минимум в 2 раза больше, а при хоть каком-то signaling keepalive — не в 2 раза, а может быть и в десятки. А (повторюсь) отказ одной транзакции рушит весь диалог, потому что так по RFC3261 положено.
G>locating SIP servers. G>http://www.ietf.org/rfc/rfc3263.txt
Естественно, я его читал.:)) И даже внимательно.:))
G>И вот это: The Stream Control Transmission Protocol (SCTP) G> as a Transport for the Session Initiation Protocol (SIP) G>http://www.ietf.org/rfc/rfc4168.txt G>
G> Multihoming: An SCTP connection can be associated with multiple IP
G> addresses on the same host.
"on the same host" — это что, для варианта, когда берутся 2-3 разных блока адресов, серверу даётся адрес из каждого из них и предполагается, что при обрыве раутинга на один из них другой поможет? Ну так для этого вообще-то традиционные раутинговые протоколы есть (типа OSPF или BGP). Реальный failover надо искать в тех случаях, когда это _разные_ хосты.
G>
over to a separate host. Since SIP proxies can run statelessly,
G> failover can be accomplished without data synchronization between
G> the primary and its backups. Thus, the multihoming capabilities
G> of SCTP provide marginal benefits.
Во-во — marginal оно и есть marginal.
N>>На HTTP ты можешь между разными серверами расшарить, например, состояние корзины покупателя (которую он модифицирует каждым кликом в браузере)? Ну да, можешь, но цена абсолютно та же, что для SIP — общее состояние, его репликация... И для HTTP каждый отдельный запрос/ответ живёт короче, чем диалог в SIP. G>Для HTTP при наличии серверной логики сессия живет гораздо длиннее, чем сессия SIP в случае телефонии.
Ну и какой уровень надёжности тебе реально нужен? Да, сессия может жить сутками и неделями (как та в rsdn где я сейчас не ввожу пароль), а звонок — например, в среднем 5 минут. Но для реальной наджёности тебе всё равно надо рассчитывать, что звонок живёт час. А за час ой сколько всяого может произойти.
G>А в простом случае — тебя для SIP хватит stateless серверов, которыми являются proxy и stateful proxy. Состояние длительное время хранится ТОЛЬКО в случае B2BUA и call stateful proxy — но это никак не отличается от случая Web App Server.
Ещё раз: если транзакция началась и сорвалась — диалог гибнет весь, потому что одна из сторон получает 408 или его аналог (внутренний таймаут), а ответ второй стороны может не дойти и поэтому суммарное состояние становится некорректным (расхождение между мнениями про, например, SDP). Поэтому писать, как ты пишешь,
stateless серверов, которыми являются proxy и stateful proxy
— некорректно. Даже если в момент гибели ноды транзакцию проходили 0.1% диалогов — эти 0.1% диалогов погибнут. Именно в этом проблема такой системы для прокси.
Ну и мне всё-таки принципиальна специфика B2BUA. А там — ты тоже подтверждаешь, что состояние хранится длительное время и с ним надо обращаться адекватно.
G>Что до разделения состояния корзины между серверами, так HTTP тут не при чем. Он никак не регламентирует такие фокусы прикладной логики — хочешь делай, хочешь нет. Я точно так же могу зашарить и состояние call stateful proxy, и применить виртуальные IP адреса, как делается и в случае веб иногда. И все, никаких проблем.
Ну кроме производительности и разнообразных race conditions типа "узел 1 запомнил состояние, но не успел передать на узел 2, а на узел 2 пришла следующая транзакция в диалоге".
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, netch80, Вы писали:
N>>Проблема не в затратах, а в том, что это таки разный код. И глюк в релизном коде ты не сможешь поймать отладочной версией. Вот это тут таки принципиально. PD>Я все-таки не понимаю. Если запрос будет переводиться из текстового вида в двоичный на выходе из броузера, а потом IIS переведет его обратно в текстовый перед тем, как отдать тебе, какой-такой разный код будет в твоем приложении ? PD>А если и не будет такого преобразования — не надо из мух слонов делать. Word поддерживает два десятка форматов, и чтение/запись в них — это разный код. И ничего страшного. Запись и чтение файла — это 1% от того, что содержит в себе Word.
У ворда _один_ родной формат (у каждой версии свой). Все остальные — экспортно-импортные, неродные. Во-первых, их конвертеры хуже тестируются и вообще пишутся. Во-вторых, это всё-таки отдельное преобразование.
Если ты хочешь уподобить ситуацию тому, как работает ворд — у тебя будет внутренние протокол и формат (по твоему вкусу — двоичные) и внешние текстовые для тех, кто этого хочет (как в случае HTTP). Значит, ты будешь отлаживать и одно, и другое. Да, в этом случае у тебя не будет проблемы между релизом и дебагом. Но эта часть работы удвоится. Тебе мало работы?;)
Здравствуйте, PaulMinelly, Вы писали:
PM>Здравствуйте, netch80, Вы писали:
N>>Здравствуйте, PaulMinelly, Вы писали:
PM>>>Клево, а поддержза возобновления _закачки_ (upload) тоже в http есть? Или надо для этого расширять каждого клиента и сервера?
N>>А как Вы это себе представляете? Частичная закачка — это семантика файлов, N>>а HTTP совсем не файловый (в основе) протокол. PM>А как Вы это узнали? В rfc так и написано вверху "передаем только гипертекст. Ни в коем случае не передаем файлы. Поэтому будьте осторожны."
Что-то я не понял — Вы тут знак вопроса пропустили?
Узнал потому, что по всему тексту rfc мало случаев слова file и они специально оговорены условиями применения.
N>>Если сервер будет отрабатывать просто файлопомойку, то, думаю, он согласится с PUT + h_Range. Но если что-то более сложное — основная проблема будет в том, как дать серверу сигнал, что всё закачали и можно что-то делать с файлом. А это уже — уровень исполняемой логики на сервере. PM>Не знаю, не знаю, по-моему это один из хреновых недочетов HTTP который исправить в его рамках нельзя. PM>Серверу сигнал можно не давать, а достаточно сказать объем закачиваемых данных — пусть он сам решает все пришло или нет.
Исправляется-то этот "недочёт" тривиально — посмотрите на любой сайт, где есть формочка с upload file. Обычно там получается генерация POST, а логика сервера переделывает это в выкладывание файла, и код, нужный на это — ничтожен по сравнению с остальной логикой. Зацикливаться на PUT я тут смысла не вижу.
А ещё бесконтрольное (а в случае "автоматической" поддержки протоколом) выкладывание файлов и их частей чревато DoS'ом.
N>Исправляется-то этот "недочёт" тривиально — посмотрите на любой сайт, где есть формочка с upload file. Обычно там получается генерация POST, а логика сервера переделывает это в выкладывание файла, и код, нужный на это — ничтожен по сравнению с остальной логикой. Зацикливаться на PUT я тут смысла не вижу.
Дело то не совсем в том как оно сейчас работает. А в том что нет докачки (upload). Закачивал 100 меговый файл, связь оборвалась. Ни в одном браузере докачки нет. Даже сделай я эту фичу, например загрузка с 50 байта по 900 — ниодин сервер ее поддерживать не будет. Почему?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
C>>>Да я знаю. Костыли можно поставить кое-где. G>>Вообще-то на это тему есть RFC, и никаких костылей не требуется. Стандартной для SIP техникой обеспечения отказоустойчивости и рапределенности является специальное правило трактовки записей DNS SRV и NAPRT, закрепленное в специальном SIP-овском RFC. C>С их помощью нельзя сделать failover для транзакций и диалогов. Поэтому идут в топку.
Для транзакций файловер вообще-то на практике не нужен. Но если очень хочется — то надо применять virtual IP. В точности так же, как и для HTTP.
G>>>>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет? C>>>SIP — он STATEFUL. HTTP банально баллансируется простым раскидываением запрос между backend-серверами. G>>SIP НЕ stateful. C>Нет. Он ЯВНО stateful, так как в самом протоколе прописаны транзакции, захватывающие несколько запросов (см. со страницы 122 в rfc3261).
Протокол — НЕ stateful, Cyberax. Ну что ты мне рассказываешь, а? SIP Proxy не обязан ничего помнить даже о текущей незавершенной транзакции. Спорим на деньги?
Насчет rfc — укажи название метода и конкретно — что за транзакция такая там прописана сказочная, которая через обычный Proxy пролезть не может.
G>>Там четыре уровня серверов — просто proxy, stateful proxy (хранит состояние транзакции — например INVITE — в этом смысле у тебя и HTTP stateful), call stateful proxy (хранит состяние звонка), и B2BUA (самая жесть). Первые два типа серверов формируют центральную часть сети, и они по сути stateless. На них уже можно сделать PBX. Остальные два — имеют мало отличий с Web Application Servers, стоят на переферии сети, и их можно откластеризовать на уровне сессий. В чем проблема? Не понимаю. Принципиальных отличий от веба не вижу. Покажешь? C>Да. Покажи мне SIP-сервер, который умеет делать failover в середине транзакции.
Да что мне его искать — он у нас работает в конторе сейчас. Приезжай в Москву — покажу . Построен на базе whackamole. Для этого подойдет вообще любой SIP Proxy Server. Потому что он не помнит состояния транзакции, он стэйтлес.
C>А я тебе покажу приложение, которое прозрачно делает failover для HTTP-запросов.
Virtual IP. Что мне смотреть-то на него? Отказоустойчивость в SIP и HTTP серверах обеспечивается СОВЕРШЕННО ОДИНАКОВО. Понимаешь? SIP by design так устроен .
