Reply вернёт бинарник, который tcp-процесс просто отправит в сеть

А почему бы возвращать не бинарник, а тупл?

Это я понимаю. Но ведь оно будет обработано раньше чем любое новое сообщение из сети которому требуются эти аттрибуты

Зачем плодить отдельный cast, усложняя код и понимание

В том то и дело, я как раз не хочу усложнять механизм вызова процессов из tcp-процесса

Нет, это не так
Сообщение из сети можно появиться в message box до reply

Не понимаю как это возможно. Ведь чтобы клиент узнал эти аттрибуты он должен получить ответ от tcp-сервера

Механизм вызова такой:

p1 sends call to p2
p2 sends reply to p1

А ты предлагаешь

p1 sends call to p2
p2 sends cast to p1
p2 sends reply to p1

И это точно сложнее и менее надёжно

Вы извините за быть может глупые вопросы, язык осваиваю + температура 39 и не спится

А, ну если так. Я-то не знаю всего контекста

p1 sends call to p2
p2 sends reply to p1

p1 sends call to p2
p2 sends cast to p1
p2 sends reply to p1

Я не то что занудствую, большое вам спасибо за помощь. Но я не понимаю, почему по предложенной вами схеме лучше

Просто эффективнее будет, сообщения же не бесплатные. Да и понять call-reply банально проще чем call-cast-reply, потому что первое более надёждное. Вариант где call-cast-reply неправильно сработает есть и не такой уж и тривиальный на первый взгляд: Между cast и reply в tcp-процесс сможет попасть ещё какое-нибудь сообщение, которое будет рассчитывать что процесс ещё находится в старом состоянии (без аттрибутов) и оно будет обработано с аттрибутами (из-за cast), но перед тем как какая-либо информация попадёт на клиент. Конечно, это может и не навредить и зависит от специфики этого tcp-процесса, но у вас нет никаких гарантий, что в будущем это не сможет породить какой-нибудь сложный и трудно отлавливаемый баг (потому что он связан с порядком сообщений, а такое трудно ловить)

Для таких случаев тут очень красиво смотрится gen_statem, но лучше пока прототип на gen_server запилить.

Я вас услышал. Ещё раз спасибо. У меня все процессы и так реализованы на gen_statem

Так а в каком состоянии окажется tcp-процесс после cast, но до reply ?
С аттрибутами, но не совсем?

Что за между cast и reply? Генсервер заблочится в call и будет ждать конкретный реплай на свой запрос. cast отработает после reply, а все что попало после каста и до реплая - ещё позже

Насколько я понимаю, до ответа на call tcp-процесс вообще не изменит state, сообщение из cast просто упадёт в очередь

Если

p1 sends call to p2
p3 sends msg to p1
p2 sends cast to p1
p2 sends reply to p1

То на p2 сообщения обработаются в таком порядке: reply, msg, cast
И вот поведение tcp-процесса во время msg не совсем ясно

Совсем ясно

Оно же обработается до передачи атрибутов

Но после пересылки пакета из reply клиенту

Из-за этого, клиенту с апгрейднутым соединением прилетит пакет для не-апгрейднутого соединения