но спасибо)

Вообще, ситуация, когда ты пытаешься читать из сокета без нужды - странная

modbus slave устройство всегда мониторит шину

но у modbus есть вариация с другим физическим уровнем - TCP

Попробуй читать из закрытого

Может там будет exception

хорошо, проверю

Это не хорошо, но можно на него завезаться

Что-то мне подсказывает что в TCP протоколе вообще все плохо с отключением

К стати, как вы компилите? Я вот пробовал в докере - удобно. Даже dmd не ставил)

Что-то мне подсказывает что в TCP протоколе вообще все плохо с отключением

Чего? Норм

Ты никак не можешь понять произошло ли оно

Ну есть нюансы

До 5 минут может "обманывать"

Но если это постоянное соединение - пинги спасут

К стати, как вы компилите? Я вот пробовал в докере - удобно. Даже dmd не ставил)

я по старинке: ставлю компилятор, dub прямо в систему без контейнеров всяких

До 5 минут может "обманывать"

так...

а может так случиться, что клиент "зайдёт под другим именем"?

а может так случиться, что клиент "зайдёт под другим именем"?

Не понял

Мне в докере неудобно, во-первых dub кеш каждый раз заново выкачивается, во вторых ни dcd ничего нельзя подключить к редактору

типа из-за плохой связи он не сможет достучаться, и откроет новое соединение, а сервер будет думать что просто тишина

Мне в докере неудобно, во-первых dub кеш каждый раз заново выкачивается, во вторых ни dcd ничего нельзя подключить к редактору

Так кеш можно монтировать

типа из-за плохой связи он не сможет достучаться, и откроет новое соединение, а сервер будет думать что просто тишина

Тоже может быть

типа из-за плохой связи он не сможет достучаться, и откроет новое соединение, а сервер будет думать что просто тишина

и клиент будет пытаться установить новое соединение, а сервер настроен как listen(1)

Так кеш можно монтировать

Можно, но иногда хочется и компилятор просто так запустить. Справку почитать, в разных режимах собрать бинарник. Если через докер все это делать то указание опций усложняется.

В итоге я все равно вернулся на LXC контейнер

Тоже может быть

какой-то способ обхода есть?

ну может id какой, чтобы по тему принудительно старое рвать если новый с таким же id соединяется?

Да, можешь сделать высокоуровневый id

Чтобы клиент свой id посылал, а у тебя уже будет хешмап, подключен ли такой id

Да, можешь сделать высокоуровневый id

на уровне передаваемых данных уже, да?

А на уровне TCP это никак не решить, так уж спроектировано.

Чтобы клиент свой id посылал, а у тебя уже будет хешмап, подключен ли такой id

не подойдёт в моей ситуации, протокол не позволяет)

тоесть modbus чётко регламентирован и добавлять туда свои id будет неправильно (потеряется совместимость с существующим софтом)

вообще может такое быть, что, например я отправил 250 байт с клиента, а серверу (slave'у по TCP) они в рваном формате пришли и я их там читаю по 10-20?

или может вообще с другой стороны обыграть ситуацию: при запросе каждый раз открывать соединение, а на принимающей стороне не хранить сокет с клиентом?

или это совсем дурно?

вообще может такое быть, что, например я отправил 250 байт с клиента, а серверу (slave'у по TCP) они в рваном формате пришли и я их там читаю по 10-20?

Может

https://theartofmachinery.com/2018/05/27/cpp_classes_in_betterc.html — надо будет на досуге разобраться и поиграться с этим)

Может

а где-то можно почитать про размер неразрывных пакетов? сколько байт точно будут одним скопом идти

Не знаю.. думаю что зависит от размера буфера сетевой карты, операционной системы, настроек сети.. MTU там какие-нибудь

TCP может окно сужать и расширять чтобы посылать больше/меньше данных

Но 1 байт я думаю это точно неразрывная порция данных )

Так что можешь посылать в первом байте признак начала данных, потом еще 2-3 байта на длину данных, а потом уже понимать сколько данных ты ждешь.

Так что можешь посылать в первом байте признак начала данных, потом еще 2-3 байта на длину данных, а потом уже понимать сколько данных ты ждешь.

в том то и дело что не могу

только длину могу

А сколько она байт?

вернее длину посылаю по протоколу modbus tcp

А сколько она байт?

максимально 260 байт кажется

весь adu

pdu для rtu и tcp одинаковый и где-то 240 байт, кажется

pdu - полезная нагрузка по сути

adu = pdu + служебная информация

блин это класс

И почему бы компилеру ошибку не выбросить, непонятно.

И почему бы компилеру ошибку не выбросить, непонятно.

Надо issue создать

или может вообще с другой стороны обыграть ситуацию: при запросе каждый раз открывать соединение, а на принимающей стороне не хранить сокет с клиентом?

Если это что-то твое внутренее

То можно сделать так:

При любом новом соединении просто закрывай старое и бери в работу новое соединение

Если это не что-то публичное!

Иначе будет проблема с безопасностью и логически будет не верно

не принято так делать, понял

Ну любое новое соединение тебя отрубает от сервака

Это не верно

Но если это исключительно внутренее - то никто кроме тебя это сделать не может

То так прокатит

и клиент будет пытаться установить новое соединение, а сервер настроен как listen(1)

В modbus tcp слейвы инициируют соединения?

а где-то можно почитать про размер неразрывных пакетов? сколько байт точно будут одним скопом идти

В ipv4 это окно меняться может

максимально 260 байт кажется

Минимальный mtu 700 примерно байт

В modbus tcp слейвы инициируют соединения?

slave как сервер, не иницирует соединение, только отвечает

Минимальный mtu 700 примерно байт

то есть всегда 700 байт неразрывно придёт?

Я бы на это не рассчитывал

Клиент сам может слать по 20 байт

Или 37

есть метод для конкатенации ассоциативных массивов?

есть метод для конкатенации ассоциативных массивов?

из-за того что это неоднозначная задача, думаю в стандартной поставке нет

Клиент сам может слать по 20 байт

ну да, но придут они не 15 и 5, а все 20 за раз же

Да я так и понял уже

ну да, но придут они не 15 и 5, а все 20 за раз же

Нет

Если клиент отослал 15 байт

И через 0.3 сек. шлёт ещё 7 байт

До сервера так и дойдет

Нужно основываться на то, сколько пришло, а не на то, сколько может прийти

До сервера так и дойдет

это то понятно, но send же сам не режет пакеты?

если они в пределах mtu

Нет

Не режет

надо почитать про modbus tcp, мне кажется там положено один запросов в один send запаковывать

это то понятно, но send же сам не режет пакеты?

Но почему бы эти пакеты не порезать промежуточным роутерам, такое может произойти имхо

в rtu там вообще по стандарту 3.5 байта времени если между байтами приходит, то это разные пакеты

Но почему бы эти пакеты не порезать промежуточным роутерам, такое может произойти имхо

беда...

беда...

Хотя с другой стороны пакет может собираться на получателе в изначально требуемую длину. Надо в общем таненбаума перечитывать

А что ты там такое пишешь?

3.5 времени передачи одного байта

в зависимости от скорости передачи

А что ты там такое пишешь?

https://github.com/deviator/modbus

Я не шарю что это такое)

Зачем применяется?