их надо специфическим образом обрабатывать, парсить в рекорды, представляющие собой соответвующую версию протокола. протокол двухсторонний, поэтому надо бы уметь в send и в recv.
а есть машина состояний — весьма сложная — однозначно get_statem, которая должна сообщение-за-сообщением кушать то, что пришло и иногда реагировать (отправляя байтики в ответ). ничто, кроме ощущения что это слишком и что это сложно тестировать, не мешает все запихнуть в один gen_statem, но хочется разделить: байтики пусть gen_server получает как {active, true}, парсит их и шлет в таком виде в gen_statem.
как это более правильно сделать — один супервайзер и два процесса — gen_statem+gen_server со стратегией one_for_all или все таки супервайзер > gen_statem, внутри которого start_link'ом линкуется экземрляр gen_server?
Если один шлёт во второй через call и обрабатывает падения, то можно rest_for_all
Два, а возможно и три процесса, смотря какая бизнес-логика. Логика(gen_statem)-middle man-транспорт. Супервизор на эту парочку(троечку) излишен, spawn_monitor из middle man. Возможно, что gen_server транспорта редуцируется до простого loop, от посылки его, возможно, тоже можно освободить, middle man, зная о маршалинге record-пакет, справится сам.
так а рестартовать это кто будет, если не супервайзер?
ты очень усложнил и пришел к плохому решению. Никогда нельзя делать active,true кроме как в тестах. Мы стараемся делать так: модуль parser, который принимает на вход состояние и байты и выдает новое состояние и поток команд. Дальше кто-то эти команды интерпретирует
а какие аргументы, почему нельзя active, true?
Обсуждают сегодня