Здравствуйте, Sinclair, Вы писали:

S>Вот природу этого спокойствия хотелось бы понять поточнее.
Это во многом психологический фактор

S>На мой взгляд, вменяемому клиенту более-менее всё равно, какой из компонентов системы уязвим. Вон, у сендмейла бинарники всегда "те же самые", зато конфиг надо беречь как зеницу ока.
Требования ВСЕХ заказчиков — подмена конфигурации без полного рестарта системы. И я их понимаю — они не хотят оставлять промплощадку без управления/диспетчеризации

S>Если имеется в виду то, что сервер типа не изменился; стоит начать посылать на него пакеты в старом формате — и всё починится, то я не понимаю в чем принципиальная разница с удаленной перепрошивкой. Потому что с ней "стоит перепрошить на сентябрьскую версию из SVN — и всё починится".
Разница во времени ответа на эти два действия

S>Зато есть некоторые опасения. Грубо говоря, смена "жесткого" протокола и связанная с ней перепрошивка — операция редкая и привилегированная. Все они лежат в логе; всегда точно известно, кто когда что и на что менял. В случае per-message изменения кода, для анализа катастрофы нужен полный лог всех сообщений.
Сама замена алгоритма по сообщению тоже всегда лежит в логе — не так часто она и происходит.

S>Типа вот сорвало у нас предохранительный клапан; почему — оказывается один из пакетов в экспериментальных целях передал некий коэффициент в виде byte, а не int; после десериализации это привело к целому переполнению при умножении, и на управляемое устройство пошёл не тот сигнал.
Устройства управления обычно яаляются многоступенчатыми. И соврать на всех шагах процедуры инициализации срабатывания — крайне маловероятно. Тем более, что если наврать на шаге адресации, то пойдет сигнал отказа срабатывания.

S>Как ты будешь отлавливать такие ситуации? Вроде смотрим — всё нормально; в системе — ни следа от вредоносного кода; откуда взялся запредельный параметр — невозможно понять.
телеуправление логируется на каждом шаге

Здравствуйте, gandalfgrey, Вы писали:
G>Сама замена алгоритма по сообщению тоже всегда лежит в логе — не так часто она и происходит.
Не понял. Речь, вроде бы, шла о том, что в самом сообщении лежит алгоритм "обработки меня". Мы же вроде всё еще про динамическую типизацию, рвзве нет?

S>>Как ты будешь отлавливать такие ситуации? Вроде смотрим — всё нормально; в системе — ни следа от вредоносного кода; откуда взялся запредельный параметр — невозможно понять.
G>телеуправление логируется на каждом шаге
Имею некоторый скепсис насчет познаваемости таких логов.

Здравствуйте, Sinclair, Вы писали:

S>Не понял. Речь, вроде бы, шла о том, что в самом сообщении лежит алгоритм "обработки меня". Мы же вроде всё еще про динамическую типизацию, рвзве нет?
Только при изменении алгоритма присходит перепосылка его, после чего он становится известным системе.

S>Имею некоторый скепсис насчет познаваемости таких логов.
Есть такое — сделать хорошее и внятное логирование — искусство.

Здравствуйте, gandalfgrey, Вы писали:

G>Здравствуйте, Sinclair, Вы писали:

S>>Не понял. Речь, вроде бы, шла о том, что в самом сообщении лежит алгоритм "обработки меня". Мы же вроде всё еще про динамическую типизацию, рвзве нет?
G>Только при изменении алгоритма присходит перепосылка его, после чего он становится известным системе.
В таком случае это обычная удаленная перепрошивка, не имеющая отношния к динамической типизации. Что и с чем мы сравниваем?

Здравствуйте, Sinclair, Вы писали:

S>В таком случае это обычная удаленная перепрошивка, не имеющая отношния к динамической типизации. Что и с чем мы сравниваем?
Нет, это просто кэширование. Алгоритмы могут приходить и подряд, в каждом сообщении — но только в случае изменения оных.
Вот примерчик :

loop(Algs)->
  receive
    {Data,F}->
      F(Data),
      loop(insert_alg(Algs,get_tag(Data),F));

    {Data,{once,F}}->
      F(Data),
      loop(Algs);

    {Data}->
      F1=get_alg(Algs,get_tag(Data)),
      F1(Data),
      loop(Algs)

  end.

Как-то вот так...
В первом случае приходит пакет данных и алгоритм, который складируется в хранилище.
Во втором — однократное использование прибежавшего алгоритма
Во третьем — используется уже заскладированный из хранилища

Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Вот-вот. Ключевое слово — процедура обновления. Сопряжённые термины: ответственность, делегирование, полномочия, допуск.
G>Не пробовали сказать такие слова какому-либо мелкому/среднему боссу в большой корпорации ? Кивать с умным видом они, конечно, будут — но это и все !

О чём и речь: пока у них есть возможность пркрываться бумажками и нет желания углубляться в существо, так всё и происходит.

ГВ>>Да, да, да. Ему самому спокойнее, даже если эти бинарники уже отодвинуты в дальний угол.
G>Ежели говорить формально — то бинарники те же, что и были.

Именно, что формально.

ГВ>>Зловеще выглядит "подгрузка исполняемого кода". А интерпертируемые скрипты — не страшно. Они ж интерпретируемые — чего их бояться-то?!
G>Скрипты проще ограничить в возможностях.

До некоторой степени. Сам понимаешь, что уязвимость системы определяется самым уязвимым звеном. Если скрипт выполняет какую-то критически важную работу, и при этом не защищён от неуправляемых обновлений, то это называется "дыркой". Пусть он даже работает в трёхслойном сандбоксе.

Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Вот вам и способ "выстрелить самому себе в ногу" на Эрланге, Лиспе и куче других языков. С++ в сравнении с ними — дитё розовощёкое.
G>Жизнь показывает иное — ежели падения или отказы ( по причине некорректности кода / входных данных / чего-то еще ) модулей на С++ случаются регулярно, то Ерланговские минисервера работают. Они просто работают. Годами.
G>Статистика на этот счет у меня богатая, так что переубедить меня будет сложно.

Let them crash?

Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Так вот, то, что вам дают возможность апдейтить код, как вам вздумается (сиречь — по упрощённой процедуре) — это означает, что ответственные лица в организации-заказчике снимают (частично) с себя ответственность за подобные последствия. А фигли? Ничего деструктивного не выполняется — это программисты во всём виноваты. И вместо того, чтобы развивать содержательную часть приёмо-сдаточных испытаний — переваливают ответственность за последствия полностью на вас.
G>Неа — ответственность лежит всегда и только на диспетчерах. Только человек может оценить ситуацию и принять решение. Например, расходомер стока воды показывает, что поток резко убыл. А потребляемая мощность автономного насоса каскадом ниже увеличилась. И что делать, эвакуировать людей с горизонта или поставить расходомер в план ремонта ?

Не, ты не понял. Диспетчер получит по ушам первым, если что пойдёт не так, но это уже критический случай. Задача руководителей — найти такие способы организации работы, чтобы снизить вероятность такого события. Я именно об этом говорил.

ГВ>>Оригинальненько так: Let them crash, особенно в контексте того, о чём ты написал ниже.
G>Это имеет значение "пусть лучше оно сдохнет, чем неправильно отработает"

Да это-то понятно.

ГВ>>Работать надо, как это ни удивительно. А не надеяться на IT-шное словоблудство.
G>Именно, что работать. А не заниматься беспрестанными приемо-сдачами. Словоблудство никому не нужно. А нужна людям работа оборудования, непрерывная, без остановок на наладку / конфигурирование.

Хех. Приёмо-сдачу устраивают не для словоблудства, а для передачи ответственности. Но это опять таки — по уму. По тому же уму, чтобы сократить количество приёмо-сдаточных мероприятий (и вообще — метаний), предварительно занимаются сбором и анализом требований, пожеланий и т.п. Но это "по уму".

ГВ>>Для деструктивного кода поле широчайшее, к сожалению. Шире просто представить невозможно.
G>Это должен быть ПРЕДНАМЕРЕННО вредоносный код

Ты не понял. Деструктивный код приводит к нарушению работы системы. Вышибанием в core dump или ошибкой округления значения температуры — не суть важно. Преднамеренность тоже не особо важна для оценки деструктивности.

Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Если бы сервер на самом деле хотели защитить, то вам не позволили бы оставлять такие "закладки" в протоколе. Ага, это чаще всего называется именно так — закладка для неконтролируемого обновления. Если ты хотел узнать про апофеоз, то вот это он и есть на самом деле.
G>Тут есть еще одно "НО" — а именно, рестарт системы при замене софта цивильным способом занимает много времени. Горячее обновление кода не спасает ситуацию, поскольку присутствуют и модули на Ерланге, и на С++, и на Тикле. Причем конфигурация многосерверная, что еще более замедляет подьем системы. Модуль-концентратор на С++ написан 7 лет назад, и при достаточно больших базах может стартовать несколько часов. Все это время система частично функциональна.

Я тебе про Фому, а ты мне про Ерёму. Технические сложности давай уж отдельно, организационные — отдельно. Я понимаю, что реальные условия обычно противоречивы и полны глупостей, но это не означает, что глупости перестают быть таковыми. В твоём случае я вижу организационную глупость, связанную с тем, что код вроде бы и нельзя обновлять, но в то же время можно. Можно называеть это корпоративным бюрократизмом, можно ещё как-то — не суть. Суть в том, что у ваших заказчиков эммм... несколько противоречивый подход к организации обновлений.

ГВ>>Что есть частный случай известного обоим сторонам описания передаваемых данных.
G>Ну разумеется, в любом случае мы исходим из наших знаний о железе и процессе работы с ним. Так что можно назвать это знание ПРЕДОПРЕДЕЛЕННЫМ

+1

ГВ>>Да нет. Селява здесь в требованиях нормативных документов и технических нюансах систем программирования.
G>А это гораздо хуже...

То-то и оно.

ГВ>>Менять процедуры хлопотно и лишняя ответственность, проходить их каждый раз, считай — прибить дело на корню, посему попросту обойти их — гораздо проще. Пусть даже для этого придётся назвать динамически обновляемое ПО "одной и той же версией", что может быть корректным по каким-то формальным признакам.
G>Вот она, сермяжно-посконная правда ! Все так и есть

Отлично, от этого и будем отталкиваться.

ГВ>>Таким образом, народ жаждет, чтобы [...]
G>А вот уже уже утрирование

Вот и хорошо. Хотя в сущности этот абзац не противоречит предыдущему.

ГВ>>Короче говоря, теперь начинается сага о терминах и их трактовках в разных контекстах, только и всего. А ты пытаешься на этом основании чуть ли не фундаментальные законы информационных технологий сотрясти.
G>Не, даже не помышлял такого ! И чего, собственно, революционного в передаче алгоритмов по проводам ? В любом случае, расчетные скрипты являются частью файла конфигурации. А подмена конфигурации ДОЛЖНА осуществляться без полного перезапуска системы

Ничего революционного в передаче алгоритмов по проводам нет. Революционными были твои формулировки задач на передачу алгоритмов. Я зацепился за твоё высказывание о том, что программа-де может самонастраиваться на обработку новых форматов данных и т.п. На поверку выходит, что никакой неожиданной "самонастройки" на самом деле нет — есть всё то, о чём упомянули твои оппоненты: предварительная подготовка требований, предварительная подготовка системы к самонастройке в виде "закладок", заранее согласованный протокол и т.п.

Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Оригиналы они, эти дядьки-КИПовцы. То есть они могут привести устройство в нерабочее состояние, так, что ли?
G>Запросто ! И не раз такое делали. Вот пример : есть такой агрегат, аппаратный концентратор УСПД. Работает крайне криво, но изготовители как бы работают над этим. Присылают новые прошивки и т.д. Но ! Эти прошивки работают корректно только на определенных модификациях агрегата. Определить это можно только разглядывая печатную плату.

Эх.

ГВ>>Ну и что? Ничего же из ниоткуда не берётся, так или иначе — сначала устаканивается сам формат данных, а прежде оного устканства появляется требование.
G>Господя ! Если б это было так ! Сначала требование, причем из разряда "вынь да положь"

Э-э-э... Ты пытаешься возразить? Последовательность-то, вроде, не меняется: требование, потом формат, потом реализация.

ГВ>>И что? Если приборы могут передавать эти данные — мы их собираем. Если не могут — обновляем прошивку с помощью КИПовцев. В любом случае про ожидаемое изменение форматов и набора данных известно заранее — у нас же есть корпоративная инструкция, предписывающая "научить" устройства таким фортелям.
G>В большинстве случаев — значительную часть данных высчитывает микросервер, на котором висит этот прибор.

Ну микросервер, так микросервер.

Здравствуйте, gandalfgrey, Вы писали:

ГВ>>И самое главное — документы-то все в порядке. И никаких формальных нарушений — все ответственные лица ответственно выполнили свою ответственную работу с документами приёмо-сдаточных испытаний.
G>Доля истины в этом есть, но только доля. Бумага и вправду прикрывает задницу, но это непрочный щит. И в случае затопления горизонта иметь будут всех, мало обращая внимания на бумажки. Потому как — денежные потери это удар по карману владельцев и топов

Загадочная это штука — корпоративный бюрократизм. И бумажки, вроде, есть, и зачем они — не ясно.

G>Интересно, а как это предполагается принимать решение о включении / выключении чего-либо без данных о состоянии зависимых цепочек ?

Это может быть реализовано либо аппаратно, либо на недоступном для обновляемого ПО уровне. Но это гипотетически, я не знаю той аппаратуры, с которой вы работаете.

Здравствуйте, gandalfgrey, Вы писали:

G>Требования ВСЕХ заказчиков — подмена конфигурации без полного рестарта системы. И я их понимаю — они не хотят оставлять промплощадку без управления/диспетчеризации

Всё равно не понятно зачем иметь возможность апгрейда кода прямо в процессе передачи данных?
Казалось бы, логично иметь отдельный протокол, по которому сервис конфигурится. Можно, довольно легко, сделать возможность автоматического отката, если что не так пошло, можно иметь централизованную систему управления версиями ПО и протоколов на разных станциях.
Всё это можно хорошо тестировать, логгировать и контролировать.
А описанный тобой всемогутер, который позволяет серверам непредсказуемо и неуправляемо меняться при каждой передаче структуры по каналу -- это какой-то рай для вирусописателя, IMHO.

Мой тебе совет. Напиши поверх вашего супер-пупер-апдейтера пару-тройку-десятку вирусов + вакцины. Запусти и попроси у владельцев $1e6. Для этого, IMHO, ваша архитектура более чем подходит...

Здравствуйте, gandalfgrey, Вы писали:

G>

G>      loop(insert_alg(Algs,get_tag(Data),F));
G>      F1=get_alg(Algs,get_tag(Data)),
G>

Ну, собственно говоря, все стало на свои места и чуда не произошло. В блоке данных явно передается неский идентификатор, который идентифицирует принадлежность данных. Т.е. протокол заранее спроектирован с поддержкой расширяемости. И реализуется расширяемость, как правило, везде однообразно -- в каждом пакете (сообщении) есть общий для всех пакетов заголовок с идентификатором и какая-то зависящая от типа пакета часть. Эта часть может называться по разному -- opaque или extension point, но суть все равно остается такой же: приемник знает, как извлечь все сообщение и как по общей части пакета определить содержимое extension point-а.

Для статически-типизированных языков в продвинутых системах сериализации это все уже давно поддерживается. Сам термин "extension points" используется в ASN.1.

Вот вы сказали, что мой механизм subclassing by extension может применяться в очень ограниченном множестве случаев. Хотя как раз для приведенного вами примера он и предназначен. Допустим, на C++ мы пакет описываем в виде базового класса:

class pdu_t : public <здесь какой-то базовый класс, навязанный системой сериализации>
  {
  public :
    pdu_t(
      // Идентификатор типа PDU.
      const pdu_type_id_t & pdu_id )
      : m_pdu_id( pdu_id )
      {}

    const pdu_type_id_t
    pdu_id() const { return m_pdu_id; }
    ...
  private :
    pdu_type_id_t m_pdu_id;
  };

От которого наследуются конкретные типы PDU:

class apply_new_factor_pdu_t : public pdu_t
  {
  public :
    float x_factor() const { ... }
    float y_factor() const { ... }
  ...
  };

class change_speed_and_acceleration_pdu_t : public pdu_t
  {
  public :
    speed_t speed() const { ... }
    acceleration_t acceleration() const { ... }
    duration_t acceleration_duration() const { ... }
  ...
  };
...

А при обработке входящих пракетов происходит десериализация PDU так, что после десериализации возвращается указатель на pdu_t:

std::auto_ptr< pdu_t > pdu( deserialize_data( in_stream ) );
pdu_processor_t * processor = get_processor( pdu->pdu_id() );
if( processor )
  processor->process( *pdu );

Где обработчики реализуют некий интерфейс pdu_processor_t:

class pdu_processor_t
  {
  public :
    virtual ~pdu_processor_t();
    virtual const pdu_type_id_t &
    pdu_id() const = 0;
    virtual void
    process( const pdu_t & pdu ) = 0;
  };

Например:

class new_factor_pdu_processor_t : public pdu_processor_t
  {
  public :
    ...
    virtual void
    process( const pdu_t & pdu )
      {
        // В принципе, здесь лучше было бы использовать dynamic_cast, но
        // в моем механизме subclassing_by_extension нельзя использовать
        // множественное наследование. Поэтому достаточно и static_cast.
        const new_factor_pdu_t & cmd = static_cast< const new_factor_pdu_t & >( pdu );
        setup_new_x_factor( cmd.x_factor() );
        setup_new_y_factor( cmd.y_factor() );
      }
  };

Выгода от использования subclassing by extension в том, что если тип данных на принимающией строне не известен, то будет десериализована только та часть объекта, которая известна принимающей стороне. В данном примере -- это базовый класс pdu_t. Программа получит pdu_id, определит, что для него нет обработчика, и соответствующим образом среагирует.

Так что вопросы поддержки расширяемых протоколов в статически-типизированных языках решены. Другое дело, что здесь требуется чуть больше писанины -- это да, зато потом обеспечивается более высокая скорость работы.

Обновлять алгоритмы обработки удаленно в C++ хоть и проблематично, но все-таки возможно. Например, можно готовые DLL-ки со специальной точкой входа пересылать. Удаленная сторона их сохраняет, подгружает и интегрирует в свой основной процесс. Хотя лучше это все-таки делать другими средствами, с возможностью быстрого отката к предыдущим версиям.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>О чём и речь: пока у них есть возможность пркрываться бумажками и нет желания углубляться в существо, так всё и происходит.
Это уже чистой воды кадровая политика : нанимают таких, которые следуют этим заветам ( "не суйся — целее будешь" и т.д ).

ГВ>Именно, что формально.
По крайней мере, ЭТО они могут понять тогда как что-то другое им обьяснять просто бесполезно.

ГВ>До некоторой степени. Сам понимаешь, что уязвимость системы определяется самым уязвимым звеном. Если скрипт выполняет какую-то критически важную работу, и при этом не защищён от неуправляемых обновлений, то это называется "дыркой". Пусть он даже работает в трёхслойном сандбоксе.
Понятно, что именно до некоторой степени ! Но тут есть парадокс : когда я собирал статистику среди телемехаников, на первом месте стояла надежность системы — и это понятно. А вот при эксплуатации на передний план незаметным образом выползает гибкость, оттесняя надежность назад. Причем у тех же самых людей, надо заметить.
Так что приходится балансировать между тем и другим. Не создается ли тут перевес в одну сторону — вопрос насущный.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Let them crash?
Именно ! Процесс, который не может с чем-то справиться, помирает. Об этом узнает супервизор и принимает некие меры — например, перезапускает покойничка. Суть в том, что не надо использовать защитное программирование и даже наоборот, надо заставлять процесс подыхать при малейшем выходе за пределы его логики. Пример :

{ok,Bin}=file:read_file("settings")

Ежели файл не прочелся/ не найден или еще чего, процесс помрет из-за ошибки паттерн матчинга, потому как функция вернет {error, чего-то там}. Если все правильно, в Bin будет лежать содержимое файла.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не, ты не понял. Диспетчер получит по ушам первым, если что пойдёт не так, но это уже критический случай. Задача руководителей — найти такие способы организации работы, чтобы снизить вероятность такого события. Я именно об этом говорил.
Тут согласен

ГВ>Хех. Приёмо-сдачу устраивают не для словоблудства, а для передачи ответственности. Но это опять таки — по уму. По тому же уму, чтобы сократить количество приёмо-сдаточных мероприятий (и вообще — метаний), предварительно занимаются сбором и анализом требований, пожеланий и т.п. Но это "по уму".
Закачикам свойственно метаться...

ГВ>Ты не понял. Деструктивный код приводит к нарушению работы системы. Вышибанием в core dump или ошибкой округления значения температуры — не суть важно. Преднамеренность тоже не особо важна для оценки деструктивности.
Есть обратимые нарушения ( после которых система может самовосстановиться ) и есть необратимые. Разница, думаю, ясна

Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Let them crash?
G>Именно ! [...]

Ну, я так и думал: если на C++ мы получаем относительно редкие, но "большие" падения, то на языках типа Эрланга — мелкие, но много. Это не в упрёк Эрлангу, не подумай. Просто обычная семантика возобновления, которая в защищённых условиях может использоваться без особых трудностей.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я тебе про Фому, а ты мне про Ерёму. Технические сложности давай уж отдельно, организационные — отдельно. Я понимаю, что реальные условия обычно противоречивы и полны глупостей, но это не означает, что глупости перестают быть таковыми. В твоём случае я вижу организационную глупость, связанную с тем, что код вроде бы и нельзя обновлять, но в то же время можно. Можно называеть это корпоративным бюрократизмом, можно ещё как-то — не суть. Суть в том, что у ваших заказчиков эммм... несколько противоречивый подход к организации обновлений.
Дык ить, если бы у одного заказчика ! У всех так, как это ни печально


ГВ>>>Таким образом, народ жаждет, чтобы [...]
G>>А вот уже уже утрирование

ГВ>Вот и хорошо. Хотя в сущности этот абзац не противоречит предыдущему.
Не противоречит, но акценты расставлены несколько иначе

ГВ>Ничего революционного в передаче алгоритмов по проводам нет. Революционными были твои формулировки задач на передачу алгоритмов. Я зацепился за твоё высказывание о том, что программа-де может самонастраиваться на обработку новых форматов данных и т.п. На поверку выходит, что никакой неожиданной "самонастройки" на самом деле нет — есть всё то, о чём упомянули твои оппоненты: предварительная подготовка требований, предварительная подготовка системы к самонастройке в виде "закладок", заранее согласованный протокол и т.п.
Гм ! Все, что я хотел сказать — это то, что мой подход позволяет сократить эти процедуры, иногда очень сильно. Но ликвидировать их совсем — не получится. Хотя бы потому, что некий начальный протокол ДОЛЖЕН быть согласован — даже если потом он будет равиваться сам по щучьему велению
Ну, и должна быть спроектирована архитектура, которая позволит производить эти модификации / самомодификации без изменения ядра системы на максимально возможный срок.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Эх.
Я уже как-то привык...

ГВ>Э-э-э... Ты пытаешься возразить? Последовательность-то, вроде, не меняется: требование, потом формат, потом реализация.
Опечатался — сначала требование, потом реализация — а потом требования меняются под прямым углом. Дескать, мы имели в виду именно это

Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Загадочная это штука — корпоративный бюрократизм. И бумажки, вроде, есть, и зачем они — не ясно.
Сие таинство, однако

ГВ>Это может быть реализовано либо аппаратно, либо на недоступном для обновляемого ПО уровне. Но это гипотетически, я не знаю той аппаратуры, с которой вы работаете.
Концевая аппаратура — это всегда голая электромеханика, даже без электроники. Вот только доступ к ней происходит через несколько цепочек