Здравствуйте, 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) Язык проще питона, изучается самым обыкновенным программистом за ОДНУ неделю.
При этом ему однако надо понять концепцию ФП. При нынешнем дефиците кадров одно понимание структуры протокола уже само по себе ценно (когда человек не начинает нести чушь про матчинг диалогов по бранчам)...
