Здравствуйте, 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 — почти одинаково, особенно с учётом того, что набор влияющих событий весьма разнообразен (сообщения сверху, снизу, от других аналогичных автоматов, таймеры и прочее).

dispatch_message( { StateName, StateData }, { MsgType, MsgData } ) -> StateName( MsgType, MsgData, StateData ).

state1( message1, Msg, State ) ->
Res = do_something( Msg, State ),
{ state2, Res }.

state1( message2, ...

и так далее. Можно разные состояния по разным модулям разнести — не проблема.

dispatch_message( { StateName, StateData }, { MsgType, MsgData } ) -> StateName:MsgType( MsgData, StateData ).

-module( stateX ).

message1( Msg, State ) -> ...

В питоне почти одинаково?

G>>4) Язык проще питона, изучается самым обыкновенным программистом за ОДНУ неделю.

N>При этом ему однако надо понять концепцию ФП. При нынешнем дефиците кадров одно понимание структуры протокола уже само по себе ценно (когда человек не начинает нести чушь про матчинг диалогов по бранчам)...

Я говорю, основываясь на реальных данных — на обучение языку уходит неделя, для незнакомых с концепцией ФП. Язык очень простой — проще явы.