caxapa.ru :: Контроль доставки сообщений (в обоих смыслах, что приемником, знать что сервер жив и пришлет, когда данные будут, что сервером, знать что клиент существует)

16+
Воскресенье
24 февраля Вход |Карта сайта | |Upload | | PARTS
	О смысле всего сущего • 0xFF • Средства и методы разработки • Мобильная и беспроводная связь • Блошиный рынок • Объявления •		•Микроконтроллеры •ARM •AVR •PIC •MSP •PLD,FPGA,DSP •Кибернетика •Технологии •Схемы, платы, компоненты
	Средства и методы разработки

Новая тема Правила Регистрация

Поиск »» Архив

•Вернуться в конференцию •Топик полностью

Скрипач (16.01.2019 18:32 - 16.01.2019 18:49) , в ответ на Но почему? Буду очень признателен за пояснения. автор: Evgeny_CD

Контроль доставки сообщений (в обоих смыслах, что приемником, знать что сервер жив и пришлет, когда данные будут, что сервером, знать что клиент существует)
Причем ПОВЕРХ TCP/IP!!! Метод отправки данных наугад, поверх надежного канала. Диссертация, не иначе. Во всех примерах - зажигание лампочки. При том что основное свойство ПРОТОКОЛА - асинхронность. Ни чем не смущает? :) Поверх TCP/IP я лампочку десяком разных способов зажгу. Без всяких брокеров. Но не асинхронно, это да :) А вот проанализировать актуальность полученного сообщения - только полями в payload. При том что структурированные данные в телеграммах, кагбэ нестандарт... Необычайно актуально для измерения температуры в помещении :)

...на самом деле, все не так как в действительности.

Ответы Развернуть
- Надежность IP канала поверх GPRS - это тема диссертации, точно. Я на этом немало собак съел. Были изобретены многие кастомные методы борьба со способами операторов экономить ресурс эфира :) (+)- Evgeny_CD(438 байт, 16.01.2019 18:53)
  - Поверх всяких G умею отправлять температуру СМС-ками. В которых есть время отправки сообщения. - Скрипач(16.01.2019 18:59)
    - Гениально! А вот когда мы будем мониторить трек машины и платить за каждую SMSку - как ты думаешь, через сколько ты вот так уже не сделаешь -> ибо юзера оторвут :) (+)- Evgeny_CD(115 байт, 16.01.2019 19:03, картинка)
      - Иии? Вы использовали MQTT? У меня периодически пробегают проекты с SMS-мониторингом. Реальные, коммерчески эффективные. (+)- Скрипач(216 байт, 16.01.2019 19:08)
        
        Еще раз - я за разумное использование SMS, особенно при использовании "малоресурсных" библиотек сжатия -> - Evgeny_CD(16.01.2019 19:26, ссылка)
        
        Я никем не прикидываюсь. Мы в свое время использовали Билайн с тарифами для M2M специальными. Там никаких пакетом безлимитных SMS не было, зато GPRS тарифицировался с округлением до 100 байт без учета количества сессий. Получалось в итоге очень (+)- Evgeny_CD(92 байт, 16.01.2019 19:16)
        
        Отправлять эту йобанную температуру в помещении я могу ОДНИ БАЙТОМ. Еще и несколько бит под идентификатор выделю. - Скрипач(16.01.2019 19:19)
        
        Слабак! У нас в проекте на Inmarsat-D для утрамбовывания в размер одного пакета был 22 битный int придуман для кодирования координат! - Evgeny_CD(16.01.2019 19:22)
        
        Координаты датчика температуры в помещении это укур. Я подразумевал пару бит под индекс:) - Скрипач(16.01.2019 19:24)
        
        В итоге наш мониторинг лесовоза жрал денег за трафик в 2 раза меньше, чем у конкурентов. Через полгода конкурентов не стало. - Evgeny_CD(16.01.2019 19:23)
  - Женя, не порите чушь. Если вы получили "температуру в помещении" и не можете сказать с уверенностью это "сейчас" или полгода назад такая температура, то нахрен нужен такой протокол?! (+)- Скрипач(149 байт, 16.01.2019 18:58 - 16.01.2019 19:02)
    - Как я сумел понять, фишка (одна из) MQTT - простота и свобода в выборе формата "полезных данных". (+)- Evgeny_CD(1069 байт, 16.01.2019 19:09)
      - Насколько я понял, свобода в выборе формата "полезных данных" это одновременно и главня проблема. Каждый лепит, что хочет и может не потрудиться сообщить формат тому, кому эти данные потом обрабатывать. (+)- AlexG(32 байт, 16.01.2019 19:29)
        
        Вообщето MQTT как-будто специально создан для JSON, и многие фреймворки именно его и используют. Ну а в JSON не проблема передать вообще что угодно, в т.ч. и временную метку. - =AlexD=(17.01.2019 09:10)
        
        Проблема не в том чтобы передать, а в том чтобы переданное обработать. Известный мне пример: Контора разрабатывает сервис сбора/архивации АСУТПшных данных. Протокол обмена MQTT. Клиенты/заказчики или, по разным причинам, не предоставляют описание (+)- AlexG(150 байт, 17.01.2019 09:35)
        
        Ну это уже не проблема MQTT, т.е. абсолютно в любом протоколе необходимо знать как минимум информационную модель и контекст данных, и если это не предоставляется, то приходится реверсинженерить. - =AlexD=(17.01.2019 09:41)
        
        Например с SNMP было бы проще. Смысл значений переменных остался бы неизвестным конечно, но их можно было бы извлечь, идентифицировать и положить в базу без какой-либо дополнительной информации. - AlexG(17.01.2019 09:54)
        
        Каждая палка имеет минимум 2 конца :) - Evgeny_CD(16.01.2019 19:33)
        
        Посмотри M-Bus. Дикий укур, но стандартизация типов и семантики данных - эталонная. - Скрипач(16.01.2019 19:38)
        
        M-Bus -> --> оно? - Evgeny_CD(16.01.2019 20:01, ссылка, ссылка)
        
        Оно. - Скрипач(16.01.2019 23:59)
        
        И совершенно не подходит для конторы, вроде Амазона, которая хочет зарабатывать, предоставляя услуги всем подряд. Поэтому у них MQTT, куда можно завернуть вообще все. - s_h_e(16.01.2019 19:47)
        
        ...причем завернуть чужое. Стать хозяином поляны, вложив в это аж полгигобайта оперативки "на брокер". - Скрипач(16.01.2019 19:51)
      - Я могу это сделать проще. Радикально проще. Лемма: в заявленной предметной области, асинхронность нахрен никому не нужна. И даже вредна. (+)- Скрипач(264 байт, 16.01.2019 19:15)
        
        Я не агитирую за MQTT. Я пока что изучаю тему. Я не говорю, что он - наше спасение. Но мне интересно, отчего он стал столь популярен. "Мир сошел с ума" меня не устраивает как объяснение. - Evgeny_CD(16.01.2019 19:31)
        
        Ответ прост - Arduino. Кроме того, популярность его - дутая. Так, детЯм побаловаться. Для этого он и придуман. Поставили в уголке "брокер" и пусть маркетологи развлекаются. Пишут статьи, нарабатывают репутацию компании. - Скрипач(16.01.2019 19:36)
        
        Вероятно этот доступный "брокер" и есть секрет распространенности. Если вам надо связать, информационно, два датчика, каждый из которых не имеет своего IP, сидит глубоко за NATом, вам надо где-то взять "брокера". Не так сложно сделать его самому, (+)- AlexBi(117 байт, 16.01.2019 20:00)
        
        А я о чем? Пионерам. Причем по таким правилам, чтобы надежно защитить бизнес от аматоров. (+)- Скрипач(54 байт, 16.01.2019 20:30)

Средства и методы разработки