ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
24 ноября
896931 Топик полностью
Связанные сообщения
XdrAsn.1
В общем случае, если задача решается в лоб использованием SQL-базы данных, то её и нужно использовать. Будет проще во многом. Др...2020-07-10
Вопрос в том, что первично. Если бинарные данные в текстовом файле (т.е. другие программы будут его осознанно использовать как т...2019-12-05
Это называется RPC (Remote Procedure Calls), ныне несколько устаревшая технология. С контроллера на хост. ARM в своих отладчиках...2019-02-05
[ASN.1] -> --> Сводный системный топик. Все стандарты (актуальные версии) внутри.2018-06-13
Битовые поля вообще за пределами одной архитектуры с одним компилятором использовать нельзя. Профессиональные решения -- опять ...2018-05-06
На компрессию ссылка не по теме. По сути ASN.1 это такая форма "бинарного XML". Когда данные передаются не неким блобом с неизве...2018-05-05
Не понял вопроса. Отвечаю. В ASN.1 и всех нижележащих форматах упаковки (PER/BER/...) подразумевается, что данные несут уже инфо...2018-05-04
fk0, легенда (17.01.2019 13:15, просмотров: 681) ответил Evgeny_CD на Скрипач, мы с тобой в противофазе :)
Истина в том, что не надо всякое дерьмище на уши развешивать и тут же в него уверовать как в абсолютную и единственную истину. Для построения M2M не нужен какой-то особенный протокол какой-то особенной фирмы. Можно сделать что угодно своё на базе уже имеющихся TCP и UDP. Только чтоб так делать нужно не жёлтую чушь и рекламу в интернете читать, а ознакомиться с уже имеющимися и зарекомендовавшими себя решениями, понять почему поступили именно так, какие задачи решены (обмен между разными компьютерными архитектурами с разными формами представления данных, разрядностью, порядком байт, возможность расширения протокола, возможность частичной интерпретации записей с пропуском тех о которых нет знания). Такими как RPC, например, построенном на XDR, или ASN.1 (BER, PER, но не XER). Это что касается кодирования сообщений, следующий шаг сам протокол, какой подход и как применить, к чему его применить, на основании чего будет выбран именно такой протокол. У размахивающих тут разными протоколами ответа на этот вопрос нет, они запрягают телегу впереди лошади выбирая вначале протокол, а затем ломают голову над тем а как его бы применить в конкретных условиях. Я опять же рекомендовал бы изучить уже имеющиеся решения, какими они обладают уже известными свойствами и известными же недостатками. Хотя бы на примере хорошо документированных протоколов использующихся в интернете. Те же TFTP (простейший протокол с квитированием), FTP/HTTP (состояние удалённой стороны кодируется в коде ответа, кодом состояния управляется автомат на своей стороне), и TCP как база для всех поток-ориентированных протоколов (чаще нет смысла изобретать свой). Modbus кстати. Благо ранние протоколы достаточно просты для понимания, и одновременно достаточно явно показывают свои свойства. В целом можно бы уже сделать два вывода, что во-первых нет смысла городить свои самодельные протоколы поверх протоколов вроде HTTP, если только устройство не является веб-серверов или явно не планируется взаимодействие с веб-сервером. Во-вторых за каждым протоколом стоит конечный автомат с явно видимыми состояниями, и вопрос скорей какой должен быть набор состояний и как они относятся к логике работы прибора.
[ZX]