Способ децентрализации программы для эвм

Способ относится к технике организации распределенных вычислений и к технике защиты информации. Техническим результатом являются преобразованные и предназначенные для распределенного исполнения части исходной программы, способные взаимодействовать друг с другом посредством среды организации распределенного взаимодействия. Способ децентрализации программы для ЭВМ включает в себя определение частей исходной программы, предназначенных для исполнения удаленно друг от друга, разделение исходной программы на части, преобразование разделенных частей для возможности их взаимодействия, организацию взаимодействия разделенных частей программы при ее исполнении. 3 з.п. ф-лы, 1 ил.

 

Изобретение относится к технике организации распределенных вычислений и защите информации.

Широко известен способ создания распределенных программ для ЭВМ «с нуля». При таком способе программа изначально задумывается как распределенная, проектируется подобным образом и реализуется на каком-либо из языков программирования.

Недостаток этого способа в том, что каждый раз необходимо повторять все этапы разработки распределенной программы для ЭВМ, что весьма ресурсоемко (требуются значительные временные и людские ресурсы). Даже с выделением общих частей распределенных программ в библиотеки, трудоемкость снижается незначительно, так как остаются проблемы аккуратного и внимательного проектирования, проработки и реализации распределенных интерфейсов взаимодействия удаленных частей программы. Дополнительно, невозможно либо крайне трудоемко при таком способе реализовать динамический выбор и логистику частей программы и их данных между сторонами исполнения. Под стороной исполнения подразумевается фактическое место исполнения частей программы (ЭВМ, процесс).

Известен способ децентрализации программы для ЭВМ «вручную» при наличии ее исходных кодов (текстов программы на произвольном языке программирования). Способ фактически представляет из себя доработку существующей нераспределенной программы для ЭВМ с целью добавления возможности распределенного исполнения.

Недостатки такого способа: трудоемкость сравнима с трудоемкостью способа создания распределенной программы для ЭВМ «с нуля», а порой даже выше, так как может потребоваться значительная переработка существующих исходных кодов для интеграции с необходимым функционалом. В случае отсутствия исходных кодов децентрализация невозможна либо крайне затруднена (ввиду ограничений полной или частичной декомпиляции двоичных кодов программы, предназначенных для исполнения на конкретных архитектурах вычислительных машин, процессоров, операционных систем и иного системного программного обеспечения). Полная декомпиляция возможна только в случае так называемых «контролируемых» двоичных кодов (например, Intermediate Language - IL, платформа Microsoft.Net и JIL, платформа Sun Java), которые содержат в себе кроме программ и их данных дополнительную информацию об их структуре, зависимостях, детальном описании и т.п. (метаинформацию).

Также известен способ разработки программы для ЭВМ (computer application development method), описанный совместно с двумя системами - компьютерной системой программирования (a computer programming system) и динамической системой программирования (a dynamic programming system) в документе US 2008/0196025 A1 (MICROSOFT CORP.), 14.08.2008 (Д1). Документ Д1 оперирует понятием "звено" (tier), которое является элементом так называемой "многозвенной" (n-tier) клиент-серверной архитектуры программ для ЭВМ. В тематической литературе наряду с термином "звено" нередко применяется синоним "уровень". На текущий момент времени наиболее распространенной "многозвенной" ("многоуровневой") архитектурой является трехзвенная клиент-серверная архитектура, где, как правило, присутствуют следующие звенья: клиент (presentation tier), сервер приложений (logic tier) и сервер базы данных (data tier).

Описанный в Д1 способ разработки программы для ЭВМ содержит два ключевых признака:

получение (acquiring) программы, не имеющей информации о звеньях (tier agnostic);

преобразование программы в многозвенный вариант для облегчения распределенного исполнения.

Также в Д1 предложены варианты способа разработки программы для ЭВМ, включающие дополнительные действия, такие как:

преобразование программы с использованием связывания с одной или несколькими предразделенными библиотеками;

преобразование программы с включением в код программы одной или нескольких процедур и/или асинхронных вызовов для облегчения взаимодействия звеньев;

преобразование программы с включением в код программы логики поддержки состояния на звеньях;

автоматическое преобразование программы как функции от анализа программы и/или контекста исполнения;

компиляция многозвенной программы в представление на промежуточном языке (intermediate language representation);

тестирование многозвенной программы в защищенной и/или симулируемой распределенной среде.

Общими признаками аналога и изобретения являются определение частей, предназначенных для распределенного исполнения, разделение программы на определенные части и преобразование разделенных частей для возможности организации их распределенного взаимодействия. Однако, следует отметить, что предложенный в Д1 способ, равно как и системы, применим только для работы над программами для ЭВМ, представленными в исходном человекочитаемом коде на одном из высокоуровневых языков программирования, и является этапом разработки программ для ЭВМ.

В отличие от аналога заявленный способ не ограничен применением на этапах разработки программ для ЭВМ, так как способ оперирует уже созданной программой, предназначенной для работы на одиночном компьютере. Более того, основной акцент возможных применений способа ставится на область "постобработки" программ для ЭВМ, например для защиты программ от несанкционированного копирования и/или использования.

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

Ни на одном из этапов раскрываемого способа не используется информация об архитектуре децентрализованной (распределенной) программы. В отличие от аналога способ не ограничен вариантами клиент-серверной архитектуры (включая многозвенные/многоуровневые архитектуры), у которых обязательно есть явно выраженный узел-инициатор запросов. Части децентрализованной программы для ЭВМ способны взаимодействовать в режиме одноранговой (пиринговой) сети, что возможно благодаря интеграции преобразованных частей программы со средой организации распределенного взаимодействия.

В заявленном способе, в отличие от аналога, не производится встраивание дополнительной логики в код программы (например, логики асинхронных вызовов) либо связывание (линковка) программы с предразделенными библиотеками. Вместо этого производится интеграция разделенных частей со средой организации распределенного взаимодействия.

Среда организации распределенного взаимодействия представляет из себя множество распределенных компонентов, взаимодействующих по сети, где каждый компонент может быть в одном из двух вариантов: в контролируемом варианте и частично-контролируемом варианте. Рекомендуется использовать интеграцию частей с контролируемыми компонентами среды организации распределенного взаимодействия, так как в таком случае отсутствует потенциальная возможность потери контроля исполнения частей программы и рассинхронизации их данных при многопоточном исполнении. Однако частично-контролируемые компоненты среды имеют ключевое преимущество, выраженное в большем быстродействии. Компоненты среды организации распределенного взаимодействия выполняют контроль исполнения распределенных частей, логистику самих частей между сторонами исполнения, логистику данных и контекстов, которыми оперируют распределенные части, между сторонами исполнения.

В способе, предложенном в аналоге, используется дополнительный этап "получение программы" (acquiring) до момента определения частей, предназначенных для распределенного исполнения, равно как и компонент "получения" (acquisition component), предназначенный для осуществления этого шага. В отличие от аналога заявленный способ не использует никаких дополнительных шагов до определения частей, предназначенных для распределенного взаимодействия.

Подавляющее количество программ для ЭВМ изначально являются централизованными, то есть не предназначенными для исполнения их частей удаленно друг от друга, на различных вычислительных машинах, в различных процессах и средах. Процесс проектирования и разработки распределенной программы всегда вызывает ряд сложностей у разработчиков, так как распределенные программы требуют особого подхода к проектированию и наличию опыта их разработки. Для значительного снижения трудоемкости при разработке распределенных программ, а также для возможности использования децентрализации программ для ограничения доступа к определенным частям (защиты частей программ) как в случае наличия исходных кодов, так и в случае их отсутствия предложен способ организации распределенных вычислений произвольной программы для ЭВМ.

Сущность предлагаемого способа заключается в том, что произвольная исходная программа для ЭВМ, как правило, изначально не предназначенная для распределенного исполнения, преобразуется в распределенный вариант этой же программы, независимо от того, в каком виде она представлена - в виде двоичного кода, исходного кода или того и другого. Способ включает в себя:

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

1. непосредственное указание частей с использованием метрик программы (например, номер строки, столбца исходного кода программы либо адрес в двоичном коде программы), что применимо как в случае наличия исходных кодов программы, так и в случае их отсутствия;

2. непосредственное указание частей с использованием меток в теле программы (например, таких как «начало части», «конец части»), что применимо в случае наличия исходных кодов программы, не применимо в случае их отсутствия;

3. непосредственное указание частей с использованием информации о функциях и процедурах программ, что применимо в случае отсутствия исходных кодов программы, но при наличии информации о наименовании и местоположении функций и процедур программы в двоичном коде (.mар-файлов);

4. обработка исходной программы с помощью программ, реализующих автоматические алгоритмы анализа, оценки и ранжирования определенных частей. В этом случае автоматические алгоритмы производят статический и динамический анализ различных частей исходной программы, измерение различных метрик для определения оценки частей по эффективности их выноса из исходной программы, а также ранжирование определенных частей. Результатом работы таких программ является список частей исходной программы, выраженный в ее метриках (например, если происходит анализ двоичного кода программы, то метриками частей будут являться адреса начала и конца каждой части в теле исходной программы);

5. комбинация автоматической обработки с непосредственным указанием частей человеком. Наиболее эффективный способ с точки зрения удобства и тонкостей определения частей.

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

- непосредственно разделение исходной программы на части по ранее определенным границам, указанным в метриках кода программы (возможно, с группировкой частей по какому-либо признаку, например по сторонам исполнения частей).

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

- преобразование разделенных частей для организации их взаимодействия посредством распределенной среды, а именно:

1. если часть программы может (будет) исполняться на частично-контролируемых сторонах исполнения среды (сторонах исполнения, в которых существует лишь опосредованная возможность контроля исполняемых программ и используемых ими данных путем модификации самих программ и интеграцией их с контролирующей логикой), то в местах разрыва (точках входа и/или выхода частей) требуется установка стабов («заглушек» в программе, замещающих или дополняющих части исходной программы, перехватывающих исполнение программы на себя и позволяющих связать программу с дополнительной логикой);

2. если часть программы будет исполняться только на полностью контролируемых сторонах исполнения (сторонах исполнения, в которых существует возможность полного контроля исполняемых программ и используемых ими данных), то установка стабов не требуется.

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

- организация распределенного взаимодействия выделенных частей. Такое взаимодействие производится посредством среды организации распределенного взаимодействия, которая представляет из себя дополнительную логику. Среда состоит из узлов сети, которые производят транспорт частей программы от стороны исполнения к стороне исполнения и данных от одних частей программы к другим частям и обратно (по какому-либо физическому, либо логическому каналу связи). Каждый узел такой сети организует логическую абстракцию «сторона исполнения» и способен полностью либо частично контролировать исполнение частей исходной программы. Подобная схема организации позволяет исполнять части исходной программы на различных сторонах исполнения различной архитектуры, отличной от архитектуры исходной программы.

На среду организации распределенного взаимодействия возлагается обязанность по определению наиболее целесообразного местоположения частей программы и их данных, если требуемое местоположение не указано явно на этапах определения частей программы и их преобразования. Среда вправе производить статистическую и иную оценку эффективности местоположения частей программы и их данных, а также доставку необходимых данных от и к частям программы как при входе и выходе исполнения определенной части, так и по запросу (осуществлять логистику данных).

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

1. определенные части программы исполняются без изменения набора инструкций на виртуальной машине:

1.1. интерпретирующего типа;

1.2. компилирующего типа (динамическом компиляторе, который при исполнении определенной части производит ее перекомпиляцию «на лету» в код архитектуры процессора, на котором исполняется эта часть, со вставками дополнительной контролирующей логики обращений к данным);

2. определенные части программы статически перекомпилируются в код новой архитектуры на этапе преобразования частей.

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

Сущность способа децентрализации программы для ЭВМ отражена на фиг.1. Для исходной программы ИП определяют (процесс П1) N-частей, указанные как части 1, 2, 3, 4,…, N-1, N, разделяют ИП на эти части (процесс П2), затем производят преобразование разделенных частей (процесс П3): для частей, которые могут исполняться частично-контролируемой средой (1, 2, 4, N), обязательно устанавливают стаб; для частей, которые могут исполняться только полностью контролируемой средой (3, N-1), установка стабов не обязательна, хотя и может быть произведена (например, для части 3). Кроме установки стабов части объединяют в группы Г1, Г2, Г3, … по произвольному признаку (на фиг.1 части объединены в группы по планируемым сторонам исполнения). Последним организуют взаимодействие преобразованных частей ИП через среду организации распределенного взаимодействия (процесс П4).

Удобство предложенного способа является в том, что среда организации взаимодействия разрабатывается только один раз для определенной архитектуры ЭВМ, процессоров и затем без изменений используется для организации распределенного взаимодействия различных программ для ЭВМ. Единственное, что потребуется произвести для каждой исходной программы - это определить части и подготовить их для распределенного исполнения. А так как это можно сделать автоматически, то предлагаемый способ представляет из себя универсальное решение децентрализации программ для ЭВМ. Способ применим для программ с произвольным количеством потоков исполнения (непосредственно процессами выполнения инструкций программы), как статическим, так и динамическим. Способ позволяет использовать для исполнения распределенных частей различные архитектуры ЭВМ, процессоров, для чего достаточно реализовать узел исполнения среды организации распределенных вычислений под такую архитектуру.

1. Способ децентрализации программы для ЭВМ, заключающийся в том, что:
для исходной программы определяют части, предназначенные для распределенного исполнения;
производят разделение программы на определенные части;
преобразовывают разделенные части для возможности организации их распределенного взаимодействия (исполнения);
отличающийся тем, что:
в качестве входных данных используют программу, созданную для работы только на одиночном компьютере и представленную либо в виде человекочитаемых исходных программных кодов на любых высокоуровневых языках программирования, либо в виде низкоуровневых исполнимых двоичных кодов, либо в виде комбинации исходных программных кодов и низкоуровневых исполнимых двоичных кодов;
дополнительно производят интеграцию преобразованных частей со средой (представляющей из себя множество взаимодействующих посредством сети связи компонентов), организующей распределенное взаимодействие преобразованных частей друг с другом вместо внедрения в каждую преобразованную часть дополнительной логики, предоставляющей возможность распределенного взаимодействия с другими преобразованными частями программы, такой как, например, логика перехвата управления при исполнении распределенных частей программы и логика передачи данных между ними по сети.

2. Способ по п.1, отличающийся тем, что части программы, предназначенные для распределенного исполнения, определяют с помощью способов автоматического статического и динамического анализа алгоритмов и способов оценки частей программы, отделение которых от исходной программы будет наиболее эффективным.

3. Способ по п.1, отличающийся тем, что исходную программу разделяют на две и более группы частей, одна из которых физически недоступна пользователю, что позволяет использовать описанный способ для защиты программ от несанкционированного доступа и копирования.

4. Способ по п.1, отличающийся тем, что выбор стороны исполнения конкретных частей программы и их данных предоставляют среде организации распределенного взаимодействия, позволяя ей динамически (во время исполнения частей программы) определять наиболее оптимальную сторону исполнения для конкретной части программы и ее данных.