Как разработать гибкий API для создания стеков протоколов Erlang
Неудовлетворенный моим нынешним подходом, я просто пытаюсь изменить способ построения стеков протоколов в Erlang. Функция, упорядоченная по важности:
Производительность
Гибкость и скорость реализации, добавление новых вариантов протокола
Это помогло бы разработке изучить варианты протокола из оболочки
Моя текущая модель ( уже описывалась в этом question ) выходит на свои пределы, помимо уродливой асимметрии send () при вызове функции и получении при помощи сообщения.
Общая картина всего механизма протокола выглядит так:
Нижняя часть:
Внизу каждого стека есть несколько портов, а иногда и gen_tcp (есть несколько идентичных стеков для независимых каналов, поэтому мы не можем быть слишком статичными здесь, просто регистрируя процессы,
Мультиплексоры, которые разговаривают с несколькими модулями (это мое определение здесь для облегчения обсуждения).
Демультиплексоры, которые имеют разные точки присоединения (в настоящее время названы атомами) для взаимодействия с модулями, обращенными вверх.
В настоящее время мои единственные демультиплексоры находятся в статическая нижняя часть стека, а не динамически создаваемая верхняя часть. Мультиплексоры в настоящее время находятся только в верхней части.
В ответах и комментариях к моей предыдущей обработке вопроса я слышал, что обычно API должен состоять только из функций, а не сообщений, и я согласен с этим, если не убежден в обратном.
Прошу прощения за пространное объяснение проблемы, но я думаю, что это все еще широко используется для всех видов реализации протоколов.
Я напишу то, что запланировал до сих пор, в ответах, а также объясню полученную реализацию и свой опыт с ней позже, чтобы достичь здесь чего-то в целом полезного.