Hi,
рассматривал ли кто применимость Erlang для реализации VoIP softswitch (для определённости — на SIP)? Интересует не принципиальная применимость, а качественные оценки адекватности подходов. YXA видел, речь не о ней (а о слое выше — диалоги, сессии).
Из того что получилось в нашем исследовании — например, прохождение всей сигнализации через один сокет (для наиболее типичного случая — UDP) и необходимость держания базы текущих диалогов является серьёзным препятствием расщеплению на слабозависимые параллельные процессы. Уровень диалога и уровень сессии очень сильно связаны, и при том что у них разные FSM — строить их в разных процессах становится весьма накладно, поэтому надо изобретать multi-FSM аналог gen_server. Достаточно много междиалогового взаимодействия (transfer, parking...), связей с внешними источниками (биллинг, RTP прокси), автоматы получаются понятными, но громоздкими. Очень желательным была замена кода на ходу, но тотальная замена работающим процессам сомнительна (иногда перестройка логики идёт очень радикальная).
Текущая реализация — одноствольник на Питоне (событийно-управляемое с вспомогательными нитями для общения с сетевыми агентами, отвечающими на запросы). Изоляция ошибок сделана перехватом исключений и работала кроме периода грубых ошибок при перестройке логики (самая тяжёлая была когда применили поле класса вместо поля объекта, полегче — когда не удалялся целый класс (в бытовом смысле) объектов), но эти ошибки не влияли на работающие процессы прямо, а приводили максимум к разбуханию в памяти. (Думаю, на Erlang'е такие же ошибки привели бы к аналогичному результату за счёт ненужных неубитых процессов.) Ремонтный командный интерфейс позволяет исправить большинство проблем (включая недоочистку) на месте. Внутренние данные достаточно пространны, предположение о передаче этого кортежами или структурами сразу вызывает головную боль. Предполагаемое межпроцессное взаимодействие местами крайне путано и громоздко (например, случай трансфера — мало того что по внутренним каналам летят полные состояния звонков, так ещё и это надо сделать так, чтобы согласовать действия разных контроллеров и при этом учесть побочные события и таймауты). Кластерное расщепление одного агента бессмысленно (кластеризацию отрабатывают внешние прокси, а внутренним раздавать один IP на несколько тазов извратнее, чем обойтись разными IP). Основная загвоздка в апгрейде — под него надо глобально перетачивать код и очень аккуратно применять, причём в зависимости от ситуации надо или менять только методы классов/модулей, или применять их и для экземпляров — готовой инфраструктуры этого действа нет. Наконец, язык понятнее среднему программисту.
Вот по всему сказанному я в раздумьях — не пропустил ли я какой-то глобальной полезности Erlang+OTP по сравнению с текущей реализацией? Руководящие и направляющие материалы прочитаны и местами законспектированы:), включая главный диссер и доку с сайта, радости они не принесли:) Легко рассказывать про тривиально параллелящиеся случаи (как у Джо пример провайдерского POP3 прокси), но вполне себе телекомовская задача у меня — уже смущает.
Здравствуйте, netch80, Вы писали:
N>Hi, N>рассматривал ли кто применимость Erlang для реализации VoIP softswitch (для определённости — на SIP)? Интересует не принципиальная применимость, а качественные оценки адекватности подходов. YXA видел, речь не о ней (а о слое выше — диалоги, сессии).
Ну, вроде как Эриксон рассматривал, нет? Разве у AXD301 нет функциональности VoIP softswitch? .
Check out the AXD 301 telephony-over-packet media gateway.
I'm sure it fits the profile pretty well. Its control system
is mostly written in Erlang, and it uses e.g. OTP's H.248.
The Erlang/OTP platform is by far the best middleware you
can find for this kind of thing. I've not seen anything that
event comes close.
/Uffe
On Thu, 13 Feb 2003, Farzin_B23 SOORI wrote:
>Dear Per;
>I am new to erlang.But i have some good experience in VoIP
>deployment;Specially i work in carrier grade level like as
>transmission the voice and signaling traffic of a high density
>telecomm switch on a IP based platform.Now i am in the selection
>phase of a real time and distributed platform to deploy my Megaco based VoIP
>system on top of it...
>So i want to ask you as a profession that , how much the erlang
>platform is hopefull for my goal? Is it scalable enough to develope
>a carrier grade system like the one i mentioned?why?
>Can you tell me some large scale and carrier grade applications
>developed with erlang so far?
>Which guys in ericsson are the most profession in erlang?
>thank you
>sincerely
>Soori
N>Из того что получилось в нашем исследовании — например, прохождение всей сигнализации через один сокет (для наиболее типичного случая — UDP) и необходимость держания базы текущих диалогов является серьёзным препятствием расщеплению на слабозависимые параллельные процессы. Уровень диалога и уровень сессии очень сильно связаны, и при том что у них разные FSM — строить их в разных процессах становится весьма накладно, поэтому надо изобретать multi-FSM аналог gen_server. Достаточно много междиалогового взаимодействия (transfer, parking...), связей с внешними источниками (биллинг, RTP прокси), автоматы получаются понятными, но громоздкими. Очень желательным была замена кода на ходу, но тотальная замена работающим процессам сомнительна (иногда перестройка логики идёт очень радикальная).
Не могу сказать — я не в теме задачи. Однако, распараллелить можно что угодно . Мы полгода назад параллелили сервер обработки котировок в познавательных целях — так там тоже сначала казалось, что масштабируемую систему сделать нельзя. Потом получилось просто и красиво.
N>Вот по всему сказанному я в раздумьях — не пропустил ли я какой-то глобальной полезности Erlang+OTP по сравнению с текущей реализацией? Руководящие и направляющие материалы прочитаны и местами законспектированы, включая главный диссер и доку с сайта, радости они не принесли Легко рассказывать про тривиально параллелящиеся случаи (как у Джо пример провайдерского POP3 прокси), но вполне себе телекомовская задача у меня — уже смущает.
Я, честно говоря, не понимаю, как Питоновское решение в такой задаче может быть проще и иметь хоть какие-то преимущества перед Эрлангом — он здесь по всем пунктам рлангу проигрывает.
1) Erlang/OTP должен лучше работать при пиковой нагрузке, он быстрее, и у него рилтаймовое время отклика.
2) На Elrang/OTP существенно, на порядок проще сделать отказустойчивое приложение.
3) Конечные автоматы на Эрланге записываются радикально проще и декларативнее, чем на Питоне, благодаря паттерн-матчингу и атомам.
4) Язык проще питона, изучается самым обыкновенным программистом за ОДНУ неделю.
Здравствуйте, netch80, Вы писали:
N> Уровень диалога и уровень сессии очень сильно связаны, и при том что у них разные FSM — строить их в разных процессах становится весьма накладно, поэтому надо изобретать multi-FSM аналог gen_server.
Как измерялось, что "весьма накладно"? Какие результаты получились?
Здравствуйте, Gaperton, Вы писали:
G>Ну, вроде как Эриксон рассматривал, нет? Разве у AXD301 нет функциональности VoIP softswitch? :).
В обычном понимании — похоже, нет. Судя по первой ссылке, он умеет транспортировать голосовые каналы поверх пакетной сети, но это не VoIP в современном смысле. Первый PDF у меня не открывается, а второй тоже ничего полезного не говорит.
Вот если бы где-то было сказано что он умеет поддерживать хотя бы одно из H.323, SIP или MGCP — это было бы VoIP. Но гугление в этом направлении ничего не даёт. Мне же нужна именно специфика VoIP с "родными" сигнализациями, и отражение этой специфики на Erlang.
G>Вот что пишет Ульф Вигер: G>http://www.erlang.org/pipermail/erlang-questions/2003-February/007383.html G>
G>Check out the AXD 301 telephony-over-packet media gateway.
G>I'm sure it fits the profile pretty well. Its control system
G>is mostly written in Erlang, and it uses e.g. OTP's H.248.
Как уже сказал — признаков поддержки хотя бы одной из трёх основных сигнализаций не видно, или же я не так ищу. Кстати, поиск вместе с RTP тоже ничего не даёт — а это показатель.
G>Не могу сказать — я не в теме задачи. Однако, распараллелить можно что угодно :). Мы полгода назад параллелили сервер обработки котировок в познавательных целях — так там тоже сначала казалось, что масштабируемую систему сделать нельзя. Потом получилось просто и красиво.
Вот я и спрашиваю про опыт. Или пусть отвлечённые, но полезные идеи. Задача-то не сильно специфическая, должна по аналогии легко переноситься.
N>>Вот по всему сказанному я в раздумьях — не пропустил ли я какой-то глобальной полезности Erlang+OTP по сравнению с текущей реализацией? Руководящие и направляющие материалы прочитаны и местами законспектированы:), включая главный диссер и доку с сайта, радости они не принесли:) Легко рассказывать про тривиально параллелящиеся случаи (как у Джо пример провайдерского POP3 прокси), но вполне себе телекомовская задача у меня — уже смущает. G>Я, честно говоря, не понимаю, как Питоновское решение в такой задаче может быть проще и иметь хоть какие-то преимущества перед Эрлангом — он здесь по всем пунктам рлангу проигрывает. G>1) Erlang/OTP должен лучше работать при пиковой нагрузке, он быстрее, и у него рилтаймовое время отклика.
Пиковая нагрузка действительно специфична по поведению, но на сейчас я не могу толком разделить эффекты разных приложений (там ещё входной/выходной прокси влияет), поэтому реальное сравнение пока недоступно.
G>2) На Elrang/OTP существенно, на порядок проще сделать отказустойчивое приложение.
Я вижу, но специфика SIP, в частности, и задачи — в крупных и частых передачах между подсистемами (1-4KB) — это и сами пакеты, и внутренние данные. Если плоская строка (как неразобранный пакет) — ещё не страшно, но сериализация и десериализация данных такого размера может быть уже заметной затратой (не мерял, интересно услышать измерения).
G>3) Конечные автоматы на Эрланге записываются радикально проще и декларативнее, чем на Питоне, благодаря паттерн-матчингу и атомам.
IMO — почти одинаково, особенно с учётом того, что набор влияющих событий весьма разнообразен (сообщения сверху, снизу, от других аналогичных автоматов, таймеры и прочее).
G>4) Язык проще питона, изучается самым обыкновенным программистом за ОДНУ неделю.
При этом ему однако надо понять концепцию ФП. При нынешнем дефиците кадров одно понимание структуры протокола уже само по себе ценно (когда человек не начинает нести чушь про матчинг диалогов по бранчам)...
N>Из того что получилось в нашем исследовании — например, прохождение всей сигнализации через один сокет (для наиболее типичного случая — UDP) и необходимость держания базы текущих диалогов является серьёзным препятствием расщеплению на слабозависимые параллельные процессы. Уровень диалога и уровень сессии очень сильно связаны,
Сессия — supervisor, диалог(диалоги?) — его дочерние процессы.
Более того, так как сессий может быть много, то над сессиями ставится еще один супервайзер.
Наврное, так, я просто специфики VoIP не знаю
N>и при том что у них разные FSM — строить их в разных процессах становится весьма накладно, поэтому надо изобретать multi-FSM аналог gen_server. Достаточно много междиалогового взаимодействия (transfer, parking...), связей с внешними источниками (биллинг, RTP прокси), автоматы получаются понятными, но громоздкими.
Для большинства этих связей скорее всего можно обойтись простым receive.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Gaperton, Вы писали:
G>>Ну, вроде как Эриксон рассматривал, нет? Разве у AXD301 нет функциональности VoIP softswitch? .
N>В обычном понимании — похоже, нет. Судя по первой ссылке, он умеет транспортировать голосовые каналы поверх пакетной сети, но это не VoIP в современном смысле. Первый PDF у меня не открывается, а второй тоже ничего полезного не говорит. N>Вот если бы где-то было сказано что он умеет поддерживать хотя бы одно из H.323, SIP или MGCP — это было бы VoIP. Но гугление в этом направлении ничего не даёт. Мне же нужна именно специфика VoIP с "родными" сигнализациями, и отражение этой специфики на Erlang.
Возможно так. Я, кстати, видел сообщения о SIP Proxi на Эрланге, который достпен под BSD лицензией. Это имеет отношение к теме?
G>>Не могу сказать — я не в теме задачи. Однако, распараллелить можно что угодно . Мы полгода назад параллелили сервер обработки котировок в познавательных целях — так там тоже сначала казалось, что масштабируемую систему сделать нельзя. Потом получилось просто и красиво.
N>Вот я и спрашиваю про опыт. Или пусть отвлечённые, но полезные идеи. Задача-то не сильно специфическая, должна по аналогии легко переноситься.
Ну блин. Все прямолинейно — начинаем с одного процесса на каждое клиентское соединение. Далее, все зависит от того, что в рамках этого соединения должно делаться. Есть подход — процесс == объект, можно с этого конца зайти. Потом, вторым этапом, наворачиваем на это фолт-толеранс, схему супервижена, и мнезию.
G>>2) На Elrang/OTP существенно, на порядок проще сделать отказустойчивое приложение.
N>Я вижу, но специфика SIP, в частности, и задачи — в крупных и частых передачах между подсистемами (1-4KB) — это и сами пакеты, и внутренние данные. Если плоская строка (как неразобранный пакет) — ещё не страшно, но сериализация и десериализация данных такого размера может быть уже заметной затратой (не мерял, интересно услышать измерения).
Автоматическая сериализация-десериализация в Эрланге чрезвычайно быстра. Явная работа с бинарными данными — binaries, удобна и тоже быстра. Тут вряд-ли стоит ожидать просадки.
G>>3) Конечные автоматы на Эрланге записываются радикально проще и декларативнее, чем на Питоне, благодаря паттерн-матчингу и атомам.
N>IMO — почти одинаково, особенно с учётом того, что набор влияющих событий весьма разнообразен (сообщения сверху, снизу, от других аналогичных автоматов, таймеры и прочее).
В питоне почти одинаково?
G>>4) Язык проще питона, изучается самым обыкновенным программистом за ОДНУ неделю.
N>При этом ему однако надо понять концепцию ФП. При нынешнем дефиците кадров одно понимание структуры протокола уже само по себе ценно (когда человек не начинает нести чушь про матчинг диалогов по бранчам)...
Я говорю, основываясь на реальных данных — на обучение языку уходит неделя, для незнакомых с концепцией ФП. Язык очень простой — проще явы.
Здравствуйте, Gaperton, Вы писали:
G>Я говорю, основываясь на реальных данных — на обучение языку уходит неделя, для незнакомых с концепцией ФП. Язык очень простой — проще явы.
Имхо много проще Явы.
Правда тут можно заметить что OTP будет заметно посложней, но в Яве можно всякие Java EE найти
Здравствуйте, Gaperton, Вы писали:
N>>Вот если бы где-то было сказано что он умеет поддерживать хотя бы одно из H.323, SIP или MGCP — это было бы VoIP. Но гугление в этом направлении ничего не даёт. Мне же нужна именно специфика VoIP с "родными" сигнализациями, и отражение этой специфики на Erlang. G>Возможно так. Я, кстати, видел сообщения о SIP Proxi на Эрланге, который достпен под BSD лицензией. Это имеет отношение к теме?
Скорее всего говорили про YXA. Библиотека симпатичная, но что-то выше прокси в ней практически не реализовано. Я же целюсь на функциональность B2BUA.
G>Ну блин. Все прямолинейно — начинаем с одного процесса на каждое клиентское соединение.
Агащаззблин(tm). Во-первых, у 99% операторов сигнализация бегает по UDP. Во-вторых, разработчики SIP, похоже, специально усложнили жизнь любителям соединений: в случае TCP, вполне возможно, что клиент отдал INVITE и закрыл соединение, а сервер должен ответ отдать по новому соединению... а во время жизни диалога тоже надо переоткрывать... в общем, о соединениях как о чём-то стабильном тут речь, увы, не идёт в принципе. Оно и на менее распределённых средствах уже кошмарик.
Я думал в качестве одного из вариантов — набрать сотню портов, при установлении диалога хэшировать его и выбирать порт, отдавая его в Contact, чтобы вывернуть входящие транзакции на конкретный процесс. Но это даёт только защиту от падения одного движка (ну зависнет 1% звонков вместо 100%), но реализацию каждого из них совсем не упрощает — процесс на сокете работает полным селектором между своими подопечными, обслуживающими диалоги и транзакции, как и в каноническом случае одного порта. И к тому же меня конкретно обломили:) проблемами файрволла — местами ничего кроме 5060/5061 не пропускается.
К сожалению, тут узкое место протокола — чтобы определить транзакцию или диалог, в рамках которых должно отрабатываться сообщение, надо сделать его предразборку (выделить via_branch, call-id, from_tag, to_tag). А это весьма сложный парсинг (грамматика, как говорится, rich) и потому затраты времени и проблемы сбоя. Сделать пул процессов-предразборщиков, надеясь на их разнос на разные ядра или процессоры (для эффективности)? Совсем изврат получается:(
G> Далее, все зависит от того, что в рамках этого соединения должно делаться. Есть подход — процесс == объект, можно с этого конца зайти. Потом, вторым этапом, наворачиваем на это фолт-толеранс, схему супервижена, и мнезию.
Mnesia мне тут, похоже, нафиг не нужна. Dict достаточен для покрытия запросов по центральному хранилищу состояния (там получается только добавление, удаление и собственно вопрос — а подать мне процесс который отвечает за данные call-id и local_tag). Хранить эти данные на диске с темпом изменения до 100 раз в секунду — смысла нет. Просто этот процесс не должен падать...
N>>Я вижу, но специфика SIP, в частности, и задачи — в крупных и частых передачах между подсистемами (1-4KB) — это и сами пакеты, и внутренние данные. Если плоская строка (как неразобранный пакет) — ещё не страшно, но сериализация и десериализация данных такого размера может быть уже заметной затратой (не мерял, интересно услышать измерения). G>Автоматическая сериализация-десериализация в Эрланге чрезвычайно быстра. Явная работа с бинарными данными — binaries, удобна и тоже быстра. Тут вряд-ли стоит ожидать просадки.
Это интереснее.
G>>>3) Конечные автоматы на Эрланге записываются радикально проще и декларативнее, чем на Питоне, благодаря паттерн-матчингу и атомам.
N>>IMO — почти одинаково, особенно с учётом того, что набор влияющих событий весьма разнообразен (сообщения сверху, снизу, от других аналогичных автоматов, таймеры и прочее).
G>dispatch_message( { StateName, StateData }, { MsgType, MsgData } ) -> StateName( MsgType, MsgData, StateData ). G>state1( message1, Msg, State ) -> G> Res = do_something( Msg, State ), G> { state2, Res }. G>state1( message2, ... G>и так далее. Можно разные состояния по разным модулям разнести — не проблема. G>dispatch_message( { StateName, StateData }, { MsgType, MsgData } ) -> StateName:MsgType( MsgData, StateData ). G>-module( stateX ). G>message1( Msg, State ) -> ... G>В питоне почти одинаково?
Выбирать обработчик по имени — не проблема. Матчинг по шаблону — можно сделать в диспетчере, давая, например, суффиксы методам:) В общем, всё равно глобального различия нет. Оно ж не статическое.
G>>>4) Язык проще питона, изучается самым обыкновенным программистом за ОДНУ неделю. N>>При этом ему однако надо понять концепцию ФП. При нынешнем дефиците кадров одно понимание структуры протокола уже само по себе ценно (когда человек не начинает нести чушь про матчинг диалогов по бранчам)... G>Я говорю, основываясь на реальных данных — на обучение языку уходит неделя, для незнакомых с концепцией ФП. Язык очень простой — проще явы.
Какие пред-условия для такого сотрудника? Грубо говоря, какие фильтры выставлять на уровне HR?
Здравствуйте, Mamut, Вы писали:
N>>Из того что получилось в нашем исследовании — например, прохождение всей сигнализации через один сокет (для наиболее типичного случая — UDP) и необходимость держания базы текущих диалогов является серьёзным препятствием расщеплению на слабозависимые параллельные процессы. Уровень диалога и уровень сессии очень сильно связаны,
M>Сессия — supervisor, диалог(диалоги?) — его дочерние процессы. M>Более того, так как сессий может быть много, то над сессиями ставится еще один супервайзер. M>Наврное, так, я просто специфики VoIP не знаю
Точно не знаете. Сессия SIP — это взаимодействие сторон с обменом SDP в пределах диалога. Сессия относится к диалогу как 1:1, если диалог сессионный (есть ещё диалоги подписки и есть смешанные), но схема состояний у них разная (достаточно, например, различия между early и late offer model — синхронизация состояний сдвинута у одного на шаг относительно другого). Супервизор тут никоим боком не годится (разве что делать из процесса диалога супервизор на один дочерний процесс — сессионный — но это получается дикий изврат).
N>>и при том что у них разные FSM — строить их в разных процессах становится весьма накладно, поэтому надо изобретать multi-FSM аналог gen_server. Достаточно много междиалогового взаимодействия (transfer, parking...), связей с внешними источниками (биллинг, RTP прокси), автоматы получаются понятными, но громоздкими. M>Для большинства этих связей скорее всего можно обойтись простым receive.
Да понятно, что оно будет receive — других примитивов приёма от других процессов/узлов вроде нет:)
Некоторое время назад я сталкивался со схожими проблемами и они так же были связаны с SIP-ом.
SIP, как сигнальный протокол еще сыроват по сравнению с его собратьями из SS7 и IN, но использовать его уже как-то можно.
Я думаю, что за этот пост меня выгонят из форума, но истина дороже.
Так вот мой Вам совет, не экспериментируйте на столь низких уровнях как транспорт, парсинг и уровень транзакций с интерпретаторами (даже если они с jit-прослойкой). Сделайте эти уровни на С или любом другом компилируемом инструменте и только transaction user (и выше) отдайте интерпретатору (какому захотите, фнкциональному или императивному). На этих уровнях интерпретаторы (эрланг в особенности) могут показать свои лучшие возможности (особенно при постороении распределнной системы повышенной надежности на основе какой-либо схеме избыточности).
Причина почему я Вам рекомендую поступить так проста. Обработка SIP трафика задача хоть и распараллеливаемая, но "сильносвязанная", т.е. части стека очень активно взаимодействуют между собой и разделять их на псевдо-процессы, обменивающиеся сообщениями — трата ценных рессурсов. Используйте на этих уровнях живые процессоры, процессы и потоки и средства их взаимодействия.
Я бы рекомендовал Вам, в качестве примера весьма эффективного SIP решения посмотреть на реализацию OpenSER (www.openser.org). Если будете смотреть, то обратие внимание на то как сделан парсинг, и как осуществляется межпроцессное взаимодействие (там есть некоторые UNIX tips).
Удачи!
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Mamut, Вы писали:
N>>>Из того что получилось в нашем исследовании — например, прохождение всей сигнализации через один сокет (для наиболее типичного случая — UDP) и необходимость держания базы текущих диалогов является серьёзным препятствием расщеплению на слабозависимые параллельные процессы. Уровень диалога и уровень сессии очень сильно связаны,
M>>Сессия — supervisor, диалог(диалоги?) — его дочерние процессы. M>>Более того, так как сессий может быть много, то над сессиями ставится еще один супервайзер. M>>Наврное, так, я просто специфики VoIP не знаю
N>Точно не знаете. Сессия SIP — это взаимодействие сторон с обменом SDP в пределах диалога. Сессия относится к диалогу как 1:1, если диалог сессионный (есть ещё диалоги подписки и есть смешанные), но схема состояний у них разная (достаточно, например, различия между early и late offer model — синхронизация состояний сдвинута у одного на шаг относительно другого). Супервизор тут никоим боком не годится (разве что делать из процесса диалога супервизор на один дочерний процесс — сессионный — но это получается дикий изврат).
N>>>и при том что у них разные FSM — строить их в разных процессах становится весьма накладно, поэтому надо изобретать multi-FSM аналог gen_server. Достаточно много междиалогового взаимодействия (transfer, parking...), связей с внешними источниками (биллинг, RTP прокси), автоматы получаются понятными, но громоздкими. M>>Для большинства этих связей скорее всего можно обойтись простым receive.
N>Да понятно, что оно будет receive — других примитивов приёма от других процессов/узлов вроде нет
Здравствуйте, netch80, Вы писали:
G>>Ну блин. Все прямолинейно — начинаем с одного процесса на каждое клиентское соединение.
N>Агащаззблин(tm). Во-первых, у 99% операторов сигнализация бегает по UDP. Во-вторых, разработчики SIP, похоже, специально усложнили жизнь любителям соединений: в случае TCP, вполне возможно, что клиент отдал INVITE и закрыл соединение, а сервер должен ответ отдать по новому соединению... а во время жизни диалога тоже надо переоткрывать... в общем, о соединениях как о чём-то стабильном тут речь, увы, не идёт в принципе. Оно и на менее распределённых средствах уже кошмарик.
Дык это — все равно сокет UDP-шный надо открывать, разве нет? Да ладно, если и соединение новое окрываетс при ответе — какая-разница, все равно есть логическое понятие сессии? Вот правильно Мамут говорит — по одному процессу на клиентскую сессию, так это назовем, а он уже будет порождать процессы для выполнения других активностей в рамках сессии. Процессы могут быть короткоживущими, это нормально.
N>К сожалению, тут узкое место протокола — чтобы определить транзакцию или диалог, в рамках которых должно отрабатываться сообщение, надо сделать его предразборку (выделить via_branch, call-id, from_tag, to_tag). А это весьма сложный парсинг (грамматика, как говорится, rich) и потому затраты времени и проблемы сбоя. Сделать пул процессов-предразборщиков, надеясь на их разнос на разные ядра или процессоры (для эффективности)? Совсем изврат получается
Есть описание в ASN.1? Тогда парсер генерируется, это должна уметь стандартная поставка Erlang. В противном случае, можно и предразбор сделать, как у табя написано. Пробовать надо. Управление пулом процессов тоже есть в стандартной либе.
G>> Далее, все зависит от того, что в рамках этого соединения должно делаться. Есть подход — процесс == объект, можно с этого конца зайти. Потом, вторым этапом, наворачиваем на это фолт-толеранс, схему супервижена, и мнезию.
N>Mnesia мне тут, похоже, нафиг не нужна. Dict достаточен для покрытия запросов по центральному хранилищу состояния (там получается только добавление, удаление и собственно вопрос — а подать мне процесс который отвечает за данные call-id и local_tag). Хранить эти данные на диске с темпом изменения до 100 раз в секунду — смысла нет. Просто этот процесс не должен падать...
Мнезия умеет не сбрасывать данные на диск, при этом реплицируя свое состояние на несколько узлов по сети — это позволяет обеспечить файловер в случае чего. Даже при записи на диск мнезия тормозить не должна — она спроектирована под быстрые лукапы и записи за O(1). Это все-таки рилтаймовая телекомовская база, не SQL-сервер.
G>>>>4) Язык проще питона, изучается самым обыкновенным программистом за ОДНУ неделю. N>>>При этом ему однако надо понять концепцию ФП. При нынешнем дефиците кадров одно понимание структуры протокола уже само по себе ценно (когда человек не начинает нести чушь про матчинг диалогов по бранчам)... G>>Я говорю, основываясь на реальных данных — на обучение языку уходит неделя, для незнакомых с концепцией ФП. Язык очень простой — проще явы.
N>Какие пред-условия для такого сотрудника? Грубо говоря, какие фильтры выставлять на уровне HR?
Никаких. Можно просить знакомства с любым функциональным или динамическим языком — это несколько ускорит дело. Хотя мы успешно учили Эрлангу людей с опытом только в С с элементами С++. А вот что по опыту Эриксона:
4.1. How long does it take to learn Erlang?
It depends. (did you expect anything else?)
With a C background (or Java, C++, Pascal, etc.), it takes most people about a week before they can write nontrivial programs, about a month to feel really comfortable and a few months before feeling ready to take on something big by themselves. It helps a lot to have someone who knows how to use Erlang around for some hand-holding.
With a background which includes another declarative language (Lisp, Prolog, Haskell, Scheme), you'll be able to hack Erlang code straight away, though learning to take advantage of the fault tolerance and concurrency takes a while.
Здравствуйте, Gaperton, Вы писали:
G>>>Ну блин. Все прямолинейно — начинаем с одного процесса на каждое клиентское соединение. N>>Агащаззблин(tm). Во-первых, у 99% операторов сигнализация бегает по UDP. Во-вторых, разработчики SIP, похоже, специально усложнили жизнь любителям соединений: в случае TCP, вполне возможно, что клиент отдал INVITE и закрыл соединение, а сервер должен ответ отдать по новому соединению... а во время жизни диалога тоже надо переоткрывать... в общем, о соединениях как о чём-то стабильном тут речь, увы, не идёт в принципе. Оно и на менее распределённых средствах уже кошмарик. G>Дык это — все равно сокет UDP-шный надо открывать, разве нет?
Угу. Один на всех (на весь узел) и никак иначе.
G> Да ладно, если и соединение новое окрываетс при ответе — какая-разница, все равно есть логическое понятие сессии? Вот правильно Мамут говорит — по одному процессу на клиентскую сессию, так это назовем, а он уже будет порождать процессы для выполнения других активностей в рамках сессии. Процессы могут быть короткоживущими, это нормально.
Он неправильно говорит, потому что не знает, что имеется в виду под сессией в SIP.
Вообще странный получается разговор — то ли мне надо добавить сюда ликбез по основным понятиям, то ли просто послать к документации:) потому что все термины смещены. Короткоживущие процессы не вопрос — транзакции так и работают.
N>>К сожалению, тут узкое место протокола — чтобы определить транзакцию или диалог, в рамках которых должно отрабатываться сообщение, надо сделать его предразборку (выделить via_branch, call-id, from_tag, to_tag). А это весьма сложный парсинг (грамматика, как говорится, rich) и потому затраты времени и проблемы сбоя. Сделать пул процессов-предразборщиков, надеясь на их разнос на разные ядра или процессоры (для эффективности)? Совсем изврат получается:( G>Есть описание в ASN.1?
В BNF:) Это не H.323, тут текстовый синтаксис. Перевести в ASN.1... боюсь, будет не так просто.
G> Тогда парсер генерируется, это должна уметь стандартная поставка Erlang.
При каких encoding rules? Боюсь, тут BER не подойдёт:)))))) Синтаксис — стиля HTTP (заголовков).
G>>> Далее, все зависит от того, что в рамках этого соединения должно делаться. Есть подход — процесс == объект, можно с этого конца зайти. Потом, вторым этапом, наворачиваем на это фолт-толеранс, схему супервижена, и мнезию. N>>Mnesia мне тут, похоже, нафиг не нужна. Dict достаточен для покрытия запросов по центральному хранилищу состояния (там получается только добавление, удаление и собственно вопрос — а подать мне процесс который отвечает за данные call-id и local_tag). Хранить эти данные на диске с темпом изменения до 100 раз в секунду — смысла нет. Просто этот процесс не должен падать... G>Мнезия умеет не сбрасывать данные на диск, при этом реплицируя свое состояние на несколько узлов по сети — это позволяет обеспечить файловер в случае чего. Даже при записи на диск мнезия тормозить не должна — она спроектирована под быстрые лукапы и записи за O(1). Это все-таки рилтаймовая телекомовская база, не SQL-сервер.
OK. Но всё равно мне кажется, что более простые средства будут ещё быстрее:)
G>>>>>4) Язык проще питона, изучается самым обыкновенным программистом за ОДНУ неделю. N>>>>При этом ему однако надо понять концепцию ФП. При нынешнем дефиците кадров одно понимание структуры протокола уже само по себе ценно (когда человек не начинает нести чушь про матчинг диалогов по бранчам)... G>>>Я говорю, основываясь на реальных данных — на обучение языку уходит неделя, для незнакомых с концепцией ФП. Язык очень простой — проще явы.
N>>Какие пред-условия для такого сотрудника? Грубо говоря, какие фильтры выставлять на уровне HR? G>Никаких. Можно просить знакомства с любым функциональным или динамическим языком — это несколько ускорит дело. Хотя мы успешно учили Эрлангу людей с опытом только в С с элементами С++. А вот что по опыту Эриксона:
G>4.1. How long does it take to learn Erlang?
G>It depends. (did you expect anything else?)
G>With a C background (or Java, C++, Pascal, etc.), it takes most people about a week before they can write nontrivial programs, about a month to feel really comfortable and a few months before feeling ready to take on something big by themselves. It helps a lot to have someone who knows how to use Erlang around for some hand-holding.
G>With a background which includes another declarative language (Lisp, Prolog, Haskell, Scheme), you'll be able to hack Erlang code straight away, though learning to take advantage of the fault tolerance and concurrency takes a while.
Я понимаю, но у них обучение более качественное:) Уровень наших вузов сейчас очень грустный.
Но, в общем, идея ясна.
Здравствуйте, AL0HA, Вы писали:
ALH>Здраствуйте, Коллега. ALH>Некоторое время назад я сталкивался со схожими проблемами и они так же были связаны с SIP-ом. ALH>SIP, как сигнальный протокол еще сыроват по сравнению с его собратьями из SS7 и IN, но использовать его уже как-то можно. ALH>Я думаю, что за этот пост меня выгонят из форума, но истина дороже. :) ALH>Так вот мой Вам совет, не экспериментируйте на столь низких уровнях как транспорт, парсинг и уровень транзакций с интерпретаторами (даже если они с jit-прослойкой). Сделайте эти уровни на С или любом другом компилируемом инструменте и только transaction user (и выше) отдайте интерпретатору (какому захотите, фнкциональному или императивному). На этих уровнях интерпретаторы (эрланг в особенности) могут показать свои лучшие возможности (особенно при постороении распределнной системы повышенной надежности на основе какой-либо схеме избыточности).
Идея понятна — возможно, как раз к этому и придём.
ALH>Я бы рекомендовал Вам, в качестве примера весьма эффективного SIP решения посмотреть на реализацию OpenSER (www.openser.org). Если будете смотреть, то обратие внимание на то как сделан парсинг, и как осуществляется межпроцессное взаимодействие (там есть некоторые UNIX tips).
SER давно используем (iptel'овский, но отличия непринципиальны). Как сделано — жутко не нравится. Труднопонимаемый чёрный ящик. Оптимизация восхищает, но работать с этим, когда, например, начинает глючить модуль TM — легче повеситься. Читать код — да, прикольно:)
ALH>Удачи!
Здравствуйте, netch80, Вы писали:
G>> Да ладно, если и соединение новое окрываетс при ответе — какая-разница, все равно есть логическое понятие сессии? Вот правильно Мамут говорит — по одному процессу на клиентскую сессию, так это назовем, а он уже будет порождать процессы для выполнения других активностей в рамках сессии. Процессы могут быть короткоживущими, это нормально.
N>Он неправильно говорит, потому что не знает, что имеется в виду под сессией в SIP. N>Вообще странный получается разговор — то ли мне надо добавить сюда ликбез по основным понятиям, то ли просто послать к документации потому что все термины смещены. Короткоживущие процессы не вопрос — транзакции так и работают.
ликбез сюда по основным понятиям конечно хорош. Мы ж не телекомщики тут, нам бы по простому проблему описать .
N>>>К сожалению, тут узкое место протокола — чтобы определить транзакцию или диалог, в рамках которых должно отрабатываться сообщение, надо сделать его предразборку (выделить via_branch, call-id, from_tag, to_tag). А это весьма сложный парсинг (грамматика, как говорится, rich) и потому затраты времени и проблемы сбоя. Сделать пул процессов-предразборщиков, надеясь на их разнос на разные ядра или процессоры (для эффективности)? Совсем изврат получается G>>Есть описание в ASN.1?
N>В BNF Это не H.323, тут текстовый синтаксис. Перевести в ASN.1... боюсь, будет не так просто.
Неполный текстовый парсер для предразбора сгенерировать тулзой типо yecc можно? Проблем сбоя не тогда будет, этот код можно считать надежным. Потом, если будет тормозить, заменить на С-шный парсер. Схема параллелизма тут проблемы представлять не должна, но мне надо знать, что там у вас за сессии, и из каких крупных стадий состоит обработка. Тут возможно несколько вариантов, как подойти к проблеме.
N>рассматривал ли кто применимость Erlang для реализации VoIP softswitch (для определённости — на SIP)? Интересует не принципиальная применимость, а качественные оценки адекватности подходов. YXA видел, речь не о ней (а о слое выше — диалоги, сессии).
imvho, вам надо сделать пилотную задачу на эланге, чтобы почувствовать его преимущества и недостатки. причём в первое время будут вылезаать в основном недостатки — из-за отсуствия у вас опыта
я лично за несколько лет использования хаскела с одной стороны узнал много о том, как рещать проблемы, которые когда-то казались неразрещшимыми, с другой — узнал о принципиальных ограничениях языка, которые не афишируются новичкам
так же и вам — нужен или человек, имеющий опыт такой работы, либо свой пилотный проект, чтобы через годик понимать самим что в нём хорошо и что плохо
Здравствуйте, Gaperton, Вы писали:
G>ликбез сюда по основным понятиям конечно хорош. Мы ж не телекомщики тут, нам бы по простому проблему описать :).
Ну попробую. Упростим до предела как общий ход событий, так и формат сообщений (выкинув всё что не нужно для самого первичного объяснения). Представим себе двух клиентов на одном домене и один прокси этого домена. Сообщение состоит из заголовка и опционального тела. Для случая VoIP тело соответствует SDP — протоколу описания сессии, а, грубо говоря, "вот тут у меня звук, тут факс, а тут видео".
Это начало транзакции установления диалога и одновременно сессии. Сессия начинается предложением (offer) своего SDP, в котором заданы адрес (в данном случае 192.0.2.1:16400), протокол (RTP с уточнением — audio/video profile, которое определяет набор кодеков) и допустимые кодеки (0 — G.711u).
Ответ B->прокси->A:
200 OK
From: a@example; tag=111
To: b@example; tag=333
Call-ID: 1
c=192.0.2.2
m=audio 32000 RTP/AVP 0
Здесь 1) ответ на исходный INVITE (завершение транзакции окончательным ответом), 2) передача предложения в пределах сессии. С момента прихода этого сообщения к A сессия установлена. Это означает, что стороны договорились о том, что они передают/принимают (audio), как (кодек 0) и куда/откуда (хосты и порты).
А отвечает подтверждением приёма:
ACK
From: a@example; tag=111
To: b@example; tag=333
Call-ID: 1
что останавливает перепосылку ответа от B и завершает установление.
С этого момента обе стороны _помнят_ что они установили связь — и что-то передают и принимают по указанным адресам (A посылает с 192.0.2.1:16400 на 192.0.2.2:32000, B — наоборот). А прокси, в отличие от них, забыл (если это именно формально прокси) — более чем транзакциями не занимается, 200 получено — из памяти вон.
Теперь, предположим, B включает факс: сообщение от B к A:
Здесь создаётся новая транзакция (на обеих сторонах — теперь для B она клиентская, а для A — серверная, то есть они поменялись ролями по сравнению с установлением), на уровне диалога — новый запрос по уже известному диалогу, а на уровне диалога — новое предложение в пределах сессии (первый поток, голосовой, деактивируется, но появляется второй). Пусть A соглашается поработать с факсом, тогда отвечает:
200 OK
From: b@example; tag=333
To: a@example; tag=111
Call-ID: 1
c=192.0.2.2
m=audio 0 RTP/AVP 0
m=image 32010 udptl t38
Здесь и ответ в транзакции, и ответ в пределах диалога, и ответ по сессии.
Опять надо подтвердить через ACK:
ACK
From: b@example; tag=333
To: a@example; tag=111
Call-ID: 1
Наконец, отработав передачу факса и завершая звонок (и диалог, и сессию), A передаёт:
BYE
From: a@example; tag=111
To: b@example; tag=333
Call-ID: 1
на что B отвечает (из вежливости;)) потому что отказаться от завершения нельзя)
200 OK
From: a@example; tag=111
To: b@example; tag=333
Call-ID: 1
Думаю, основа взаимодействия понятна. Но в реальности данных значительно больше — вот пример из реального лога (только IP поменял):
Сессия — это целевое взаимодействие между сторонами, ради которого всё и затевается:), которое для SIP является payload'ом (как бы это перевести...), и описывается средствами другого протокола. Для голоса протокол — SDP, а сессия реализуется через обмен предложениями и ответами на них. Для IM (второе важное применение) — протоколы обмена сообщениями.
Диалог — средство логической организации на сторонах представления о длительном (от секунд до часов) взаимодействия, используемого как транспорт для сессии.
Транзакция — кратковременное (для большинства ситуаций ограниченного секундами) взаимодействия при установлении, обновлении и завершения диалогов, а также однократных взаимодействий не-сессионного характера (например, передачи сообщений).
Взаимодействие уровней сессии, диалога, транзакции и транспорта (там есть ещё свои заморочки;)) — принципиально не отличается от уровневого взаимодействия в любом другом стеке протоколов. События нижележащего уровня могут передаваться на вышележащий, а команды с вышележащих — на нижележащий. Но отдельным вопросом является взаимодействие диалога и сессии. И на всех уровнях нужна передача полных сообщений, возможно, с урезанием отдельных частей, но не более того.
N>>В BNF:) Это не H.323, тут текстовый синтаксис. Перевести в ASN.1... боюсь, будет не так просто. G>Неполный текстовый парсер для предразбора сгенерировать тулзой типо yecc можно? Проблем сбоя не тогда будет, этот код можно считать надежным. Потом, если будет тормозить, заменить на С-шный парсер. Схема параллелизма тут проблемы представлять не должна, но мне надо знать, что там у вас за сессии, и из каких крупных стадий состоит обработка. Тут возможно несколько вариантов, как подойти к проблеме.
Парсер — наверно, можно:) но я не смотрел на то, как привязывается в нём семантика к синтаксису.
Параллелизм — в основе я уже описывал, повторю главное. Модули транспортов практически не параллелятся (я не могу считать параллельностью деление по транспорту типа UDP/TCP/SCTP и по адресу для транспорта, включая хост и порт). Для UDP лимитирующий фактор — сокет, для TCP — пул соединений с маппингом удалённого адреса в него и автомата отсылки (грубо говоря, его логика: найти существующее соединение; если есть, попытаться отослать по нему; если не было или оборвалось — попытаться открыть новое; в это ещё вмешивается возможная множественность адресов и DNS-запросы). SCTP — аналогично. Полученные сообщения можно парсить (дорогая операция даже в инкрементальном экономном варианте) параллельно, если сделать пул процессов.
Процесс на транзакцию, на базовый уровень диалога и на сессионный уровень. Вот сессионный диалог и сессия — плохо делятся. А одно из самых неустранимых узких мест — центральная база диалогов.
Здравствуйте, netch80, Вы писали:
N>Процесс на транзакцию, на базовый уровень диалога и на сессионный уровень. Вот сессионный диалог и сессия — плохо делятся. А одно из самых неустранимых узких мест — центральная база диалогов.
Мне кажется, что имеет смысл держать центральную распределенную базу диалогов и по процессу на диалог. То есть, когда сообщение приходит — берем процесс с этим диалогом и даем ему сообщение на обработку. Если процесса нет (упала нода с ним) — поднимаем его состояние из базы и создаем новый.
Здравствуйте, Cyberax, Вы писали:
N>>Процесс на транзакцию, на базовый уровень диалога и на сессионный уровень. Вот сессионный диалог и сессия — плохо делятся. А одно из самых неустранимых узких мест — центральная база диалогов. C>Мне кажется, что имеет смысл держать центральную распределенную базу диалогов
Я что-то слабо понимаю, что такое _центральная_ _распределённая_ база.:)
Реплицируется на несколько процессов, и у каждого можно спросить?
Кстати, асинхронность взаимодействия тут тоже может оказать интересные эффекты. Например, диалог 1 запросил регистрацию, диалог 2 — тоже, по диалогу 1 пришёл трансфер на диалог 2, а регистрация диалога 2 ещё не произведена. Порядок поступления сообщений из разных источников, насколько я помню, не гарантируется. Что — считать диалог созданным (и отвечать об этом) только после подтверждения регистрации (=>ещё два состояния в автомате)? Или можно обойтись без этого?
C> и по процессу на диалог. То есть, когда сообщение приходит — берем процесс с этим диалогом и даем ему сообщение на обработку. Если процесса нет (упала нода с ним) — поднимаем его состояние из базы и создаем новый.
Здравствуйте, netch80, Вы писали:
C>>Мне кажется, что имеет смысл держать центральную распределенную базу диалогов N>Я что-то слабо понимаю, что такое _центральная_ _распределённая_ база. N>Реплицируется на несколько процессов, и у каждого можно спросить?
Примерно. Посмотри на Mnesia (классное название для базы данных ).
N>Кстати, асинхронность взаимодействия тут тоже может оказать интересные эффекты. Например, диалог 1 запросил регистрацию, диалог 2 — тоже, по диалогу 1 пришёл трансфер на диалог 2, а регистрация диалога 2 ещё не произведена. Порядок поступления сообщений из разных источников, насколько я помню, не гарантируется. Что — считать диалог созданным (и отвечать об этом) только после подтверждения регистрации (=>ещё два состояния в автомате)? Или можно обойтись без этого?
Порядок гарантируется при синхронной репликации.
C>> и по процессу на диалог. То есть, когда сообщение приходит — берем процесс с этим диалогом и даем ему сообщение на обработку. Если процесса нет (упала нода с ним) — поднимаем его состояние из базы и создаем новый. N>По-моему, перебор.
Еще я бы сделал load ballancer, работающий на уровне IP.
То есть, сделать несколько узлов с одинаковым IP, закатать их в VLANы и поставить перед ними load ballancer, который будет запоминать ассоцацию клиент-узел. Узлы шлют load ballancer'у регулярный heartbeat.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>я лично за несколько лет использования хаскела с одной стороны узнал много о том, как рещать проблемы, которые когда-то казались неразрещшимыми, с другой — узнал о принципиальных ограничениях языка, которые не афишируются новичкам
А можешь отписать немного по этому вопросу?. А то я как решил посмотреть детальнее на Haskell. Думаю и другим будет интересно. Правда лучше наверно отдельным постом, ну да модераторы потом если нужно будет отделять ветку.
.
