Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP. C>[стошнило] C>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет.
?! Смотри, как это делается. Несколько способов. http://www.cs.columbia.edu/techreports/cucs-011-04.pdf
Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет?
Здравствуйте, netch80, Вы писали:
N>Два разных кода для дебага и релиза?
Между прочим, это обычная ситуация для EXE файлов. И проблемы с тем, что Debug работает, а Release нет — известны, но вполне решаются.
>Я надеюсь, среди нормальных людей нет таких, кто всерьёз (а не потрепаться) думает о таком)
Ну насчет всерьез — уже поздно. Раньше думать надо было.
N>P.S. На самом деле, один частный случай подобного рода можно придумать. Но с границей не между отладочной и релизной версией, а скорее между режимами работы для каждой из них — если есть проверенная библиотека ASN.1 представлений, можно переключаться между BER (или вообще PER) для обычной работы и XER для случая, когда надо в чём-то разобраться. Но я думаю, что первый же глюк собственно библиотеки выбросит эту идею нафигъ и, возможно, с её автором.
А не преувеличиваешь ли все эти проблемы ? Почему все же для EXE это никого не смущает, более того, только так и бывает — никто не отлаживает сразу Release, и никто не распространяет Debug ?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Gaperton, Вы писали: G>>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP. S>(Побежал в гугл читать про SIP)
Про него есть замечательная книга — Demistifying SIP. Ее можно найти в электронном виде. Она показывает, как SIP вписывается в Internet Conferencing Architecture, дополняя другие протоколы IETF.
Здравствуйте, Gaperton, Вы писали:
C>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. G>?! Смотри, как это делается. Несколько способов. G>http://www.cs.columbia.edu/techreports/cucs-011-04.pdf
Да я знаю. Костыли можно поставить кое-где.
G>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет?
SIP — он STATEFUL. HTTP банально баллансируется простым раскидываением запрос между backend-серверами.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Cyberax, Вы писали:
C>>Здравствуйте, Gaperton, Вы писали:
G>>>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP :). Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP. C>>[стошнило] C>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. G>?! Смотри, как это делается. Несколько способов. G>http://www.cs.columbia.edu/techreports/cucs-011-04.pdf
Ага, ага. Ключевая фраза:
To avoid storing SIP transaction states in the subnet router, this method is only recommended for stateless
SIP proxies that use only UDP transport and treat each request as independent without maintaining any
transaction state.
Настоящего failover'а там нет (при котором разделяются и используются всеми данные транзакций и диалогов), а то что есть — общий трёп на тему "в DNS можно писать более одного адреса для имени". Шарят данные регистраций — ну это сейчас любой умеет.
G>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет?
На HTTP ты можешь между разными серверами расшарить, например, состояние корзины покупателя (которую он модифицирует каждым кликом в браузере)? Ну да, можешь, но цена абсолютно та же, что для SIP — общее состояние, его репликация... И для HTTP каждый отдельный запрос/ответ живёт короче, чем диалог в SIP.
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>Два разных кода для дебага и релиза? PD>Между прочим, это обычная ситуация для EXE файлов. И проблемы с тем, что Debug работает, а Release нет — известны, но вполне решаются.
Это не разный код (надеюсь), а разные режимы компиляции, между которыми можно и переходный сделать (дебаг только части файлов).
>>Я надеюсь, среди нормальных людей нет таких, кто всерьёз (а не потрепаться) думает о таком;)) PD>Ну насчет всерьез — уже поздно. Раньше думать надо было.
Этого не понял.
N>>P.S. На самом деле, один частный случай подобного рода можно придумать. Но с границей не между отладочной и релизной версией, а скорее между режимами работы для каждой из них — если есть проверенная библиотека ASN.1 представлений, можно переключаться между BER (или вообще PER;)) для обычной работы и XER для случая, когда надо в чём-то разобраться. Но я думаю, что первый же глюк собственно библиотеки выбросит эту идею нафигъ и, возможно, с её автором.:) PD>А не преувеличиваешь ли все эти проблемы ? Почему все же для EXE это никого не смущает, более того, только так и бывает — никто не отлаживает сразу Release, и никто не распространяет Debug ?
Потому, что твоя аналогия с debug/release сборками некорректна.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Gaperton, Вы писали:
G>>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP :). Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.
KP>Полностью согласен! После довольно продолжительных ковыряний в данном протоколе о нем остались самые лучшие воспоминания :up:
Значит, ты не столкнулся с тем, что нет вообще ни одной реализации без багов и тараканов подхода. Ух завидую.
Здравствуйте, Centaur, Вы писали:
C>Так писать неправильно. Символ '&', являющийся частью URI, при использовании в HTML должен кодироваться в &.
Именно об этом и речь.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>А не преувеличиваешь ли все эти проблемы ? Почему все же для EXE это никого не смущает, более того, только так и бывает — никто не отлаживает сразу Release, и никто не распространяет Debug ?
Не преувеличивает. И есть люди, которые отлаживают Release (а что ты имел в виду под "проблемы известны, но решаемы"?), и есть даже те, кто поставляет дебаг.
Но это, впрочем, не очень важно.
Я бы хотел услышать хоть один аргумент в пользу такого подхода. То, что ты можешь объявить любые проблемы несущественными, я понял уже давно.
Ок, зачем нам эти несущественные проблемы? Что мы выиграем? Трафик? Бугога. Как известно, лучшие оптимизации — алгоритмические.
В данном случае это означает, что гораздо больше трафика можно выиграть, научившись вообще не передавать никакие данные в уместных случаях.
А также за счет прозрачного сжатия контента. Прозрачность хороша тем, что прикладному программисту не нужно заниматься сжатием вручную, осваивая тонкости протокола.
А также за счет умения передавать данные по частям.
А также за счет умения передавать не сами данные, а только разницу между предыдущим закэшированным состоянием и новым.
Бинарность/небинарность с точки зрения оптимизации отходят на второй план. За исключением тех случаев, когда вышеописанные возможности исчерпаны, а результаты не устраивают.
А это и есть та самая крайняя необходимость, о которой говорит Игорь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Pavel Dvorkin, Вы писали:
N>>>Два разных кода для дебага и релиза? PD>>Между прочим, это обычная ситуация для EXE файлов. И проблемы с тем, что Debug работает, а Release нет — известны, но вполне решаются.
N>Это не разный код (надеюсь),
Нет, не надейся. Разный бинарный код. Да, впрочем, и source иногда тоже
#ifdef DEBUG
...
а разные режимы компиляции, между которыми можно и переходный сделать (дебаг только части файлов).
Можно. Но не стоит. Проблем с библиотеками не оберешься — они для Debug и Release разные, а две одновременно подключить сложно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А не преувеличиваешь ли все эти проблемы ? Почему все же для EXE это никого не смущает, более того, только так и бывает — никто не отлаживает сразу Release, и никто не распространяет Debug ?
Debug не распространяют, но тем не менее определенные отладочные средства в релиз таки включают, типа снятия мини-дампов в случае падения, логирования. Реальность ведь такова, что невозможно отловить все баги на этапе тестирования. А в случае с серверами ситуация немного другая. Во-первых, воспроизвести проблему бывает достаточно сложно, особенно, когда проявляется только под нагрузкой, и далеко не всегда есть возможность полной эмуляции рабочей системы. И как здесь может помочь дебажная версия протокола, если нужно продиагносцировать проблему на рабочем сервере? Во-вторых, цена простоя сервера бывает очень высока, это с экзешником можно ковыряться сколько угодно (хотя тоже не всегда), а с серверами проблему часто нужно фиксить "на лету" и быстро. Поэтому протокол лучше делать сразу читабельным.
Что касается двух версий протокола debug/release, это несерьезно. Если уж нужна читабельная отладочная информация, то конвертить бинарные данные лучше перед выводом в лог, но и здесь могу быть свои проблемы, например, в случае некорректности входных данных. Короче говоря, не нужно усложнять то, что можно не усложнять
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, netch80, Вы писали:
N>>Здравствуйте, Pavel Dvorkin, Вы писали:
N>>>>Два разных кода для дебага и релиза? PD>>>Между прочим, это обычная ситуация для EXE файлов. И проблемы с тем, что Debug работает, а Release нет — известны, но вполне решаются.
N>>Это не разный код (надеюсь),
PD>Нет, не надейся. Разный бинарный код. Да, впрочем, и source иногда тоже
PD>#ifdef DEBUG PD>...
Пока это различие не меняет основную логику — код одинаковый. А делать, чтобы оно меняло основную логику — это ССЗБ.
N>>а разные режимы компиляции, между которыми можно и переходный сделать (дебаг только части файлов).
PD>Можно. Но не стоит. Проблем с библиотеками не оберешься — они для Debug и Release разные, а две одновременно подключить сложно.
Ну это только у вас с вижуал студией такие сложности.;)) В более... мнэээ... нормальных местах делается иначе.
PD>>#ifdef DEBUG PD>>...
N>Пока это различие не меняет основную логику — код одинаковый. А делать, чтобы оно меняло основную логику — это ССЗБ.
А что, замена одного формата данных на другой (при том. что между ними имееется взаимно-однозначное соответствие, о других вариантах и речи нет) так-таки и меняет логику ?
N>Ну это только у вас с вижуал студией такие сложности.) В более... мнэээ... нормальных местах делается иначе.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, netch80, Вы писали:
PD>>>#ifdef DEBUG PD>>>...
N>>Пока это различие не меняет основную логику — код одинаковый. А делать, чтобы оно меняло основную логику — это ССЗБ.
PD>А что, замена одного формата данных на другой (при том. что между ними имееется взаимно-однозначное соответствие, о других вариантах и речи нет) так-таки и меняет логику ?
А что, благородный дон не видит разницы между, например, fprintf(out, "%d", val) и fput_be32(out, val)?
;)))
N>>Ну это только у вас с вижуал студией такие сложности.;)) В более... мнэээ... нормальных местах делается иначе. PD>No comment. :-)
Эт' хорошо — что Вы хотя бы понимаете, что не MSDev единым живо человечество.
Здравствуйте, Игoрь, Вы писали:
И>Что касается двух версий протокола debug/release, это несерьезно.
Не debug/release (я это просто в качестве примера привел), а просто двух версий. Запрос может, грубо говоря, передаваться в двух формах, первый байт определяет форму, остальные суть содержимое запроса. Кстати, конвертировать из бинарного в текстовый мог бы сам сервер (IIS) перед передачей приложению, так что ты бы ничего и не заметил.
Впрочем, ладно, не стоит продолжать. Я просто хотел сказать, что выбор или-или не единственный, вот и все.
> И>>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать > текстовый формат, и только в случае крайней необходимости — бинарный. > > PD>А нельзя вместо "или" употребить "и" ? Вместо того , чтобы выбрать один > из них, реализовать оба ? И написать конвертор из одного в другой ? При > отладке используем текстовый, в релизе — бинарный ? > > Два разных кода для дебага и релиза? Я надеюсь, среди нормальных людей нет > таких, кто всерьёз (а не потрепаться) думает о таком) > > P.S. На самом деле, один частный случай подобного рода можно придумать. Но > с границей не между отладочной и релизной версией, а скорее между режимами > работы для каждой из них — если есть проверенная библиотека ASN.1 > представлений, можно переключаться между BER (или вообще PER) для > обычной работы и XER для случая, когда надо в чём-то разобраться. Но я > думаю, что первый же глюк собственно библиотеки выбросит эту идею нафигъ > и, возможно, с её автором. >
На самом деле ничего страшного в подобном подходе нет, я при разработке
самопальной rpc примерно так и делал. Переключалось правда не
дебагом/релизом, а опцией в конфиге сервера.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Cyberax, Вы писали:
C>Вот говоришь ты по телефону. А сервер вдруг сдох (выпал из сети, etc.). Хотелось бы, чтобы оно всё само переключило на резервный сервер, без обрыва соединения.
Ты не понял. Я сам офигел от постановки вопроса.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, netch80, Вы писали:
N>P.S. На самом деле, один частный случай подобного рода можно придумать. Но с границей не между отладочной и релизной версией, а скорее между режимами работы для каждой из них — если есть проверенная библиотека ASN.1 представлений, можно переключаться между BER (или вообще PER) для обычной работы и XER для случая, когда надо в чём-то разобраться.
В WCF тоже похожая фишка есть — XML там все равно, но можно передавать его в бинарном виде.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
. Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.
)
