Маленькая оговорка: я вообще-то поспорить люблю, стараюсь себя сдерживать, чтоб не уходить в спор ради спора, все-таки помнить о теме. Но не всегда получается
Надеюсь на понимание
Andrey_B писал(а):
Заметьте, что в приведенном вами примере системой является связка человек-автомобиль-сервис.
Разумеется. Но в ситуации "я+карбюратор" элемент "сервис" не является позарез необходимым.
Среднестатистический автолюбитель не справится с ремонтом автомобиля в дороге будь то карбюратор или инжектор.
Поправка: из водителей "старой закалки" с карбюратором справится минимум каждый десятый. (А если речь будет идти о выживании, то может и больше) С инжектором не справится никто. (Ну не видел я людей, которые в дальнюю дорогу берут паяльник и осциллограф...)
Но если говорить о моей жене, например, она не починит ни того, ни другого, так что ДЛЯ ЭТОГО СЛУЧАЯ действительны все Ваши доводы об экономичности и экологичности...
Любое устройство хорошо работает в рамках какой-то задачи, внешних условиях и требований пользователя. Именно поэтому Ethernet. Почему? Потому что а) стандарт Ethernet хорошо изучен и документирован б) Поддерживается большим количеством устройств в) хорошо распространен г) Детально проработаны протоколы верхнего уровня д) Дешев е) Доступен в продаже
Именно поэтому HTTP. Почему? Потому что любой слесарь, державший хоть раз в руках мышь способен понять принципы работы устройства, перенастроить его, составить любые элементарные программы для управления устройством. Устройство максимально стандартно и воспроизводимо. Вся документация, схемы и ПО есть в Интернете.
Если Вы держите в уме возможность делать такие штуки НА ПРОДАЖУ - тогда я снимаю все вопросы, и говорю что Вы правы! Тогда довод про "любого слесаря" становится очень весом. Но если Вы делаете это для себя и ТОЛЬКО ДЛЯ СЕБЯ - тогда при чем здесь "любой слесарь" ?!
Возможно, я не с того конца начал
Попробую изложить "правильно":
Я совершенно убежден, что для задач автоматического управления, подобных Вашей, протокол UDP в принципе значительно лучше подходит!
Отступление: не знаю кто Вы по профессии. Вы скромно называете себя "человеком, незнакомым с", но мне кажется, что Ваши знания превосходят знания любого из 2-х десятков программистов, что сейчас сидят вокруг меня. Так что могу ошибиться в выборе правильного уровня детализации, не пинайте сильно...
Итак, UDP изначально заточен на передачу коротких сообщений, не требующих подтверждения (именно то, что требуется в большинстве Ваших случаев). Поэтому UDP
быстрее, меньше грузит сеть и всю сетевую аппаратуру. Меньше объем кода для реализации. Я исхожу из того, что каждый килобайт содержит, условно, 0.23 бага
(цифра вписана от балды, но думаю что порядок именно такой)
Недостаток TCP я покажу на таком примере. Допустим, Вы передаете каждые 10 секунд данные о температуре. И допустим, что на пути следования пакета роутер пошел на перезагрузку, которая длится 30 секунд. Что произойдет в случае UDP ? - вы просто потеряете 2-3 измерения. В большинстве случаев это не трагично. А что будет, если Вы их шлете по TCP ?...
1. Потеряются как несколько пакетов данных, так и встречные ACK/NAK.
(Обе стороны должны будут это хозяйство хранить в буферах, чтобы передать как только появится возможность. Как там у AVRки с памятью под буфера ?) В результате возникнет таймаут до 2-3 минут (по опыту работы с ssh). Вы получите все переданные отсчеты, но - сперва Вы получите из очереди 3 неактуальных отсчета, посланных во время перезагрузки роутера, затем несколько значений,
ставших неактуальными, пока TCP восстанавливал нормальную последовательность, и только после этого придет актуальное значение. (Т.е. -
значительно позже, чем пришло бы по UDP)
2. Если связи не будет "слишком долго" (сколько точно - надо смотреть конкретные реализации), то TCP-соединение просто будет разорвано, и после восстановления связи надо будет заново проделать всю процедуру установления соединения. Причем, если Вы начнете устанавливать соединение до того как восстановилась сеть - получите громадный таймаут, так что "простое" решение восстанавливать соединение в цикле окажется просто скверным с т.з. оперативности. Чтоб этого избежать, надо еще усложнить алгоритм - например, пинговать в цикле, и только когда пришел ответ на пинг, открывать сокеты...
Ну а если мы шлем команды ? Представьте себе, что Вы (в смысле - Ваш сервер) несколько раз шлете устройству команды включить-выключить-включить-выключить. А связи нет - как в предыдущем случае. Все ваши команды аккуратно выстраиваются в очередь, и после восстановления связи устройство получит их все подряд, хотя они давно стали неактуальны...
Это - плата за "гарантированную доставку".
Правда, если Вы выбрали http, как протокол "верхнего уровня", проблемы с очередью Вы обошли. Каким образом ? Да просто-напросто Вы занимаетесь
эмуляцией UDP over TCP. Открыть сокет, послать пакет, получить пакет, закрыть сокет - это разве не есть эмуляция UDP ?
Но только с двадцатикратным перерасходом ресурсов как машинных, так и собственных. В русском языке это зовется "из пушки по воробьям".
За что же платим ? - а за возможность раз в 2 года поуправлять устройством с неподготовленного компьютера.
Вопрос: стОит ли оно того ?
Как маркетинговый ход, ради облегчения внедрения - однозначно, стОит. А если делать "для себя, чтоб работало хорошо" - сомневаюсь... Если же хочется сделать так потому, что хочется поэкспериментрировать, наделать кирпичиков для будущего здания, которое целиком пока еще виднеется очень смутно - это третий вариант, отличный и от первого и от второго, совершенно другой мотив, и в этом случае я критиковать не возьмусь! Но для "боевой" системы, не для экспериментальной - я бы все-таки настаивал на UDP
А теперь возьмем какой-нибудь более узкий промышленный или не дай бог разработанный самостоятельно интерфейс, протокол, систему сообщений и т.д. Вместо стандарта, проверенного годами, вместо хорошо протестированного и знакомого и легко поддающегося дебагу TCP/IP-HTTP мы получаем что-то экзотическое в наших домашних условиях. Вот вам и Сибирь. Для ремонта такого устройства потребуется выписывать шамана с бубном из Тунгусских лесов.
Не увлекайтесь - over http у Вас все равно ходит СОБСТВЕННЫЙ протокол. Единственное его преимущество - его можно назвать "самодокументированным". Но трудозатраты на эту "самодокументированность" вообще-то
больше, чем на написание нормальной документации к какому-нибудь VPupkin-BUS.
Вдумайтесь в то, о чем вы говорите. Вариантов много. Сценариев развития ситуации много. Совершенно неизвестно, какая система даст в том или ином случае более приемлемый вариант - сложная или простая. Тем более, что сложность системы - характеристика сугубо субъективная. Может случиться и так, что сложная "выручит", а может наоборот.
О! Согласимся пока на том, что эта тема ОЧЕНЬ сложная. Не первый год ломаю над этим голову, но до сих пор даже для себя не смог сформулировать критерии "надежности". Вернее, смог сформулировать один: в любой автоматизированной системе хочу иметь большую кнопку, вырубающую всю автоматику разом, чтоб человек мог перехватить управление, и никакие электронные жуки не смогли этому воспрепятствовать.
А ежели человек по условиям задачи вмешаться не может, то как ставить один автомат следить за другим автоматом - к этой задаче я даже подходов не нащупал
Очевидные решения для частных случаев - не в счет. Хочется именно "общие принципы" выработать...
Так какой смысл теоретизировать на эту тему? Это форум не о философии, это форум о реальных задачах и реальных путях решения. А "если бы, да кабы", "двойной сбой", "тройной сбой" - это, извините, сочинения на тему как я провел лето.
Да я, вообще-то, с отверткой в руках себя чувствую уверенней, чем с книгой
Любая ненулевая вероятность рано или поздно реализуется. А с учетом
общей склонности к недооценке каких-то факторов - гораздо больше "рано". Дурацкий пример: если вероятность ошибочного чтения байта с диска равна 10E-12 - это хорошо ? Вроде бы нормально! Встряхиваем головой и понимаем: это значит на терабайтном диске 1 файл гарантированно битый
Другой дуракций пример: кошка роняет клавиатуру, при ее падении нажимаются последовательно F8, Enter (Norton Commander). Какова вероятность ? Ничтожно маленькая. Произошло на моих глазах.
Если вероятность неприятности =10E-9 - можем с чистой совестью ей пренебречь. Но если число таких "независимых" неприятностей =10Е7, то вероятность что какая-то одна из неприятностей реализуется оказывается чертовски высокой! И я не знаю другого пути повышения надежности кроме "перебора" на тему "а какая бяка еще может случиться, и как нам этого избежать"
1) Включить котел 2) Включить насос контура 3) Полностью открыть привод 3-х ходового (а это включить ключ на 120 с). Вероятность возникновения 3-х разных ошибочных команд невелика.
А какова вероятность, что программа получит температуру в доме = -255 градусов ? Там есть подпрограмма "сомнение в достоверности данных" ?
Но, допустим. И что? Что произойдет? Учитывая, что температура отдачи радиатора зависит от температуры в помещении, температура стабилизируется где-нибудь на 40, ну 45 градусах, вряд ли больше.
Думаю - больше. (Точнее можно сказать, если Вы дадите данные о режиме отопления в самый сильный мороз) "Но, допустим" При такой температуре резко (в десятки раз) возрастает вероятность выхода из строя любой электроники, и значительно возрастает вероятность перерастания в пожар случайной искры. Хотя бы фокусировка солнечных лучей от неровностей стекла - при 20 градусах она еще "безопасна", а при 45 - заметно "опасней".
Девушку спрашивают:
- Какова вероятность встретить на улице динозавра ?
- 50% !
- ???!
- Либо встречу, либо нет !
Короче: я не говорил о
гарантированном пожаре !
Здесь оперируем вероятностями. Если при 20 градусах вероятность была, скажем, 10Е-5, то при 45 она вырастает в 100, а то и в 1000 раз. Была "пренебрежимо мала", стала просто "мала", уже не "пренебрежимо". Такой подход возражений не вызывает ?
Котел имеет собственную автоматику и будет, работая на максимуме, держать температуру теплоносителя 83-85 градусов - не больше. А сдохнет сервер от перегрева, так все сразу выключится, так как питание ключей, которые обеспечивают работу насоса, берется из БП сервера.
Удачное решение! Кроме шуток. Можно сказать - "задарма" сделали такую дополнительную защиту. Но подыхание сервера может случиться и в процессоре (при 45, если кулер не пылесосили год - вероятность не подыхания, но зависона - я бы сказал повыше 50%!), а БП будет послушно питать мертвое железо.
stanislav.l писал(а):Таких примеров можно напридумывать тысячи.
Давайте еще попробуем.
Зачем? Можно и этот "добить"
Вы автоматику котла проверяете каждый день ? Вот, котел не включался месяц - Вы готовы поклясться здоровьем своих близких, что эта автоматика в идеальном состоянии, и вероятность ее глюка "
пренебрежимо мала" ?
Сорри за количество. Все-таки не уследил за собой
Ну не стирать же теперь - так старался