Hi,
рассматривал ли кто применимость Erlang для реализации VoIP softswitch (для определённости — на SIP)? Интересует не принципиальная применимость, а качественные оценки адекватности подходов. YXA видел, речь не о ней (а о слое выше — диалоги, сессии).

Из того что получилось в нашем исследовании — например, прохождение всей сигнализации через один сокет (для наиболее типичного случая — UDP) и необходимость держания базы текущих диалогов является серьёзным препятствием расщеплению на слабозависимые параллельные процессы. Уровень диалога и уровень сессии очень сильно связаны, и при том что у них разные FSM — строить их в разных процессах становится весьма накладно, поэтому надо изобретать multi-FSM аналог gen_server. Достаточно много междиалогового взаимодействия (transfer, parking...), связей с внешними источниками (биллинг, RTP прокси), автоматы получаются понятными, но громоздкими. Очень желательным была замена кода на ходу, но тотальная замена работающим процессам сомнительна (иногда перестройка логики идёт очень радикальная).

Текущая реализация — одноствольник на Питоне (событийно-управляемое с вспомогательными нитями для общения с сетевыми агентами, отвечающими на запросы). Изоляция ошибок сделана перехватом исключений и работала кроме периода грубых ошибок при перестройке логики (самая тяжёлая была когда применили поле класса вместо поля объекта, полегче — когда не удалялся целый класс (в бытовом смысле) объектов), но эти ошибки не влияли на работающие процессы прямо, а приводили максимум к разбуханию в памяти. (Думаю, на Erlang'е такие же ошибки привели бы к аналогичному результату за счёт ненужных неубитых процессов.) Ремонтный командный интерфейс позволяет исправить большинство проблем (включая недоочистку) на месте. Внутренние данные достаточно пространны, предположение о передаче этого кортежами или структурами сразу вызывает головную боль. Предполагаемое межпроцессное взаимодействие местами крайне путано и громоздко (например, случай трансфера — мало того что по внутренним каналам летят полные состояния звонков, так ещё и это надо сделать так, чтобы согласовать действия разных контроллеров и при этом учесть побочные события и таймауты). Кластерное расщепление одного агента бессмысленно (кластеризацию отрабатывают внешние прокси, а внутренним раздавать один IP на несколько тазов извратнее, чем обойтись разными IP). Основная загвоздка в апгрейде — под него надо глобально перетачивать код и очень аккуратно применять, причём в зависимости от ситуации надо или менять только методы классов/модулей, или применять их и для экземпляров — готовой инфраструктуры этого действа нет. Наконец, язык понятнее среднему программисту.

Вот по всему сказанному я в раздумьях — не пропустил ли я какой-то глобальной полезности Erlang+OTP по сравнению с текущей реализацией? Руководящие и направляющие материалы прочитаны и местами законспектированы:), включая главный диссер и доку с сайта, радости они не принесли:) Легко рассказывать про тривиально параллелящиеся случаи (как у Джо пример провайдерского POP3 прокси), но вполне себе телекомовская задача у меня — уже смущает.