RU2814437C1 - Способ и устройство для генерации удаленных вызовов - Google Patents

Abstract

Изобретение относится к области вычислительной техники, а в частности к способу и устройству генерации удаленных вызовов RPC. Технический результат заключается в сокращении вычислительных ресурсов для запуска приложения на устройстве. Технический результат достигается за счет выполнения способа, содержащего этапы, на которых: получают запрос на использование вычислительных ресурсов (BP); получают информацию, описывающую процесс обработки данных посредством BP; преобразуют структуру данных, содержащихся в информации, в промежуточный код, структура данных которого представляет собой абстрактное синтаксическое дерево (AST); на основе упомянутого промежуточного кода формируют файл с конфигурацией удаленных вызовов (RPC); на основе данных файла RPC генерируют заменяющие библиотеки, и код сервера; направляют код сервера на сервер для его запуска; направляют заменяющие библиотеки на устройство пользователя, предназначенные для запуска и перенаправления команд на обработку данных, предназначенных для BP, на сервер для их обработки с помощью удаленных BP и получения результатов обработки данных. 2 н. и 4 з.п. ф-лы, 2 ил.

Description

ОБЛАСТЬ ТЕХНИКИ

[001] Представленное техническое решение в общем относится к области вычислительной техники, а в частности к способу и устройству генерации удаленных вызовов RPC (Remote Procedure Call).

УРОВЕНЬ ТЕХНИКИ

[002] Из уровня техники известны различные решения, направленные на генерацию удаленных вызовов RPC. RPC является достаточно популярным решением в сфере создания распределенных систем и микросервисных архитектур. За годы, прошедшие с момента первых, посвященных RPC идей, появилось бесчисленное количество реализаций. Ниже будут отмечены лишь самые популярные и известные из них. Все существующие реализации подвержены все той же проблеме: они ориентируются на полный контроль над интерфейсами и протоколами взаимодействия, не уделяя внимание сценарию сделать доступными удаленно уже существующие, доступные локально, решения. Данные реализации не позволяют автоматически преобразовывать существующий локальный API в удаленный.

[003] Описанные далее решения стали стандартами в индустрии в первую очередь по той причине, что эти решения предоставляют необходимые уровни абстракции для массового использования. За рамками обзора ниже остаются решения, не располагающие возможностью генерации серверной и клиентской частей. В случае необходимости поддерживать произвольный API, потребуется не только реализовать непосредственно программную логику, включая в том числе вызовы штатного API, но и написать на том или ином языке программирования само «оборачивание» вручную. Такой подход имеет право на существование только в качестве движка, лежащего в основе полноценной системы, и сам по себе представляет довольно ограниченный интерес.

[004] Sun RPC (ONC RPC)

Корпорация Sun Microsystems стала первым масштабным популяризатором идей RPC. В ходе работ над Network File System (NFS), инженеры Sun Microsystems разработали систему, ставшую неформально известной как Sun RPC. Впоследствии реализация была открыта, а ее аспекты - описаны в соответствующих RFC уже под названием ONC RPC (Open Network Computing Remote Procedure Call).

[005] ONC RPC вводит дополнительный уровень абстракции в виде предметно-ориентированного языка для описания интерфейсов RPC, Interface Definition Language (IDL). Данный язык близок по стилю к языку программирования С, переосмысливая, впрочем, ряд его конструкций довольно нестандартным образом. IDL не может быть автоматически создан из кода на С без сторонних утилит, что существенно уменьшает практическое применение IDL для применения в неконтролируемом API. Учитывая, что описания пишутся вручную, равно как и программная логика, низкоуровневость и многословность ONC RPC IDL составляют большую проблему с точки зрения разработки и поддержки конечного решения.

[006] Необходимо отметить, что код, генерируемый из IDL, является заглушками. Модель генерации предполагает, что сгенерированный код будет в дальнейшем правиться и дополняться аспектами программной логики. Иными словами, IDL генерирует точки входа на стороне клиента и сервера, а вот программную логику, включая непосредственно вызов, например, штатного API, приходится описывать вручную, либо решать сторонними методами. Сгенерированный код, по крайней мере, на языке С, не отличается большой читаемостью; отдельной проблемой является также то, что пользователь должен знать об особенностях кодогенерации и понимать принципы трансляции из IDL в программный код.

[007] Для сериализации данных используется формат XDR. Плюсом данного выбора является тот факт, что формат стандартизирован и широко известен, реализован в виде отдельной библиотеки и не зависит от транспортного уровня. К минусам можно отнести тот факт, что XDR крайне слабо поддерживает версионирование и частичный разбор сообщений, что является проблемой для сценария, когда необходимо поддержать несколько версий произвольного неконтролируемого API. В условиях, когда интерфейсы RPC для новой версии API нельзя сгенерировать, данная проблема также существенно уменьшает потенциал использования. Базовые средства версионирования, существующие на уровне IDL, с большим трудом решают указанные проблемы в условиях контролируемого API, а в условиях неконтролируемого неспособны решить эти проблемы вовсе.

[008] Основным пользователем ONC RPC по-прежнему является NFS, как по историческим причинам, так и ввиду того, что NFS детально описывает взаимодействие между клиентом и сервером, включая свой слой версионирования; таким образом, NFS заведомо избегает ряда известных сложностей ONC RPC. Использование же ONC RPC для произвольных проектов затруднительно, как ввиду сложности IDL, так и по причине необходимости написания большого объема кода вручную. Но если в случае контролируемых API эти проблемы можно обойти путем установления некоего стандарта, как это делает NFS, то для API от третьих лиц проблема носит нерешаемый характер без написания дополнительных средств генерации.

[009] gRPC/protobuf

В качестве ответа на некоторые проблемы ONC RPC и с целью сделать его более универсальным за пределами NFS и любительских проектов, корпорация Google разработала новый формат сериализации, protobuf, и средства RPC, использующие этот формат, - gRPC.

[0010] protobuf занимает в иерархии gRPC то же место, что и IDL в ONC RPC. protobuf устраняет ряд недостатков ONC RPC IDL посредством введения новых абстракций и изменения формата IDL. Тем не менее, как и ONC RPC IDL, protobuf прежде всего исходит из принципа создания RPC одновременно с сервисом, и не уделяет повышенного внимания задаче «оборачивания» в RPC уже существующих интерфейсов. Кроме того, система типов protobuf, в отличие от С-подобного ONC RPC IDL, крайне плохо накладывается на реалии публикуемых API, которые зачастую написаны именно на языках С и С++.

[0011] Ввиду непригодности уровня IDL для решаемой задачи, рассматривать остальные преимущества и недостатки gRPC в рамках данного документа не имеет смысла. Отметим лишь, что, в дополнение к сложности «оборачивания» интерфейсов, gRPC также генерирует заглушки, обязывая пользователя дополнять код вручную. Также отметим использование НТТР2 в отличие от более традиционных низкоуровневых TCP/UDP; это может оказаться проблематичным, если возникает необходимость использовать нестандартный транспорт.

[0012] Cap'n Proto

Cap'n Proto создан одним из авторов protobuf, как дальнейшее развитие заложенных в protobuf идей и концепций. Как и protobuf, Cap'n Proto ориентирован на разработку новых интерфейсов, а не на адаптацию существующего API. Все изменения синтаксиса IDL и прочие улучшения направлены в первую очередь на создание сервисов и клиентов «под ключ» либо на устранение недостатков используемого gRPC транспорта, а значит, данное решение также не подходит для решения проблемы «оборачивания» произвольного API. Стоит отметить, что Cap'n Proto является довольно новой технологией, пока не получившей широкого распространения.

[0013] Apache Thrift

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

[0014]AVA

Automatic Virtualization of Accelerators (AVA) - это проект с открытыми исходным кодом, представляющим из себя исследовательскую систему для автоматической виртуализации различных акселераторов в том числе GPU, разработанную в лаборатории Техасского университета в Остине. Особенностью проекта является использование предметно-ориентированного языка (DSL) для описания интерфейсов и их входных, выходных аргументов и последующей автоматической генерации кода сервера и клиентской библиотеки.

[0015] Стоит отметить, что, несмотря на хороший потенциал, фреймворк располагает рядом проблем. Главной проблемой является отсутствие автоматической генерации кода для существующих интерфейсов: все интерфейсы должны быть описаны посредством AVA DSL. Второй критичной проблемой проекта является сложность поддержки, прежде всего - необходимость добавления проприетарных расширений в язык С++ (особые секции кода с соответствующей маркировкой, уникальные ключевые слова и прочие дополнения). Для поддержания этих расширений, AVA вводит свой собственный уровень разбора кода С++, дополняя его также сторонними библиотеками - в частности, Glib и boost. Читаемость сгенерированного кода не удовлетворяет требованиям разработки, а стоимость доведения данного решения до промышленного стандарта оказывается неизмеримо высокой ввиду сложности системы. По всей видимости, именно поэтому проект AVA так и остался прототипом: на данный момент кодовая база заморожена и не развивается.

СУЩНОСТЬ ТЕХНИЧЕСКОГО РЕШЕНИЯ

[0016] Технической проблемой или задачей, поставленной в данном техническом решении, является создание простого и надежного способа и устройства генерации удаленных вызовов RPC.

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

[0018] Указанный технический результат достигается благодаря осуществлению способа генерации удаленных вызовов RPC, выполняемого по меньшей мере одним вычислительным устройством, содержащего этапы, на которых:

- получают запрос на использование вычислительных ресурсов (BP);

- получают информацию, описывающую процесс обработки данных посредством BP;

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

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

- на основе данных файла RPC генерируют заменяющие библиотеки, описывающие правила передачи данных от клиента к серверу и правила приема данных от сервера, и код сервера, описывающий правила приема данных от клиента и правила передачи данных от сервера к клиенту;

- направляют код сервера на сервер для его запуска на сервере;

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

[0019] В одном из частных примеров осуществления способа информация, описывающая процесс обработки данных посредством BP, содержит: информацию о типах данных, идентификаторы интерфейсов BP, которые упомянутые типы данных обрабатывают, а также инструкции по обработке данных.

[0020] В другом частном примере осуществления способа этап формирования файла RPC содержит этапы, на которых осуществляют: поиск в файле AST информации, описывающей процесс обработки данных посредством BP, и на основе типа данных и правила обработки данных определение, требуется ли упомянутую информацию включить в файл RPC.

[0021] В другом частном примере осуществления способа дополнительно выполняют этап проверки целостности и корректности данных, включающий: извлечение сущностей из файла RPC; извлечение сущностей из файла AST; сравнение упомянутых сущностей для проверки целостности и корректности данных.

[0022] В другом частном примере осуществления способа дополнительно выполняют этапы:

- извлечения информации о протоколах взаимодействия между клиентом и сервером для передачи между ними данных;

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

[0023] В другом предпочтительном варианте осуществления заявленного решения представлено устройство генерации удаленных вызовов RPC, содержащее по меньшей мере одно вычислительное устройство и по меньшей мере одну память, содержащую машиночитаемые инструкции, которые при их исполнении по меньшей мере одним вычислительным устройством выполняют вышеуказанный способ.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0024] Признаки и преимущества настоящего изобретения станут очевидными из приводимого ниже подробного описания изобретения и прилагаемых чертежей, на которых:

На Фиг. 1 - представлен пример реализации системы обработки информации.

На Фиг. 2 - представлен пример общего вида вычислительного устройства.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

[0025] Ниже будут описаны понятия и термины, необходимые для понимания данного технического решения.

[0026] В данном техническом решении под системой подразумевается, в том числе компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, четко определенную последовательность операций (действий, инструкций).

[0027] Под устройством обработки команд подразумевается электронный блок либо интегральная схема (микропроцессор), исполняющая машинные инструкции (программы).

[0028] Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройств хранения данных. В роли устройства хранения данных могут выступать, но не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические приводы.

[0029] Программа - последовательность инструкций, предназначенных для исполнения устройством управления вычислительной машины или устройством обработки команд.

[0030] Представленное решение позволяет использовать удаленно произвольный существующий и работающий локальный (доступный только на том же вычислительном узле) API, поставляемый в виде заголовочных файлов или ином формате. Например, для работы с GPU используется проприетарный API NVidia CUDA, позволяющий использовать локально установленные GPU. Для нужд облака необходимо обеспечить возможность работать с этими GPU удаленно. RPCNG решает задачу удаленного вызова локальной реализации API для тех случаев, когда этот API стандартизирован. Процесс удаленного вызова может осуществляться посредством перехвата методов локальной реализации API при механизмах подмены библиотек, например, LD_PRELOAD или DLL injection (также возможны аналогичные методы подмены для других языков программирования). Подмененная библиотека осуществляет удаленный вызов сервиса на другом узле. Удаленный сервис вызывает локальную версию оригинального API.

[0031] Построение такого рода библиотеки удаленных вызовов вызывает определенную сложность в связи с тесной зависимостью от реализации локального API. Также удаленный API должен меняться в соответствии с изменениями, возникающими в новых версиях локального API.

[0032] Представленное решение позволяет минимизировать временные и производственные затраты за счет частичной автоматизации построения удаленного API. Данная задача решается посредством автоматической генерации удаленной реализации из локального API. Для преобразования локального API в удаленный мы вводим промежуточное представление (IDL), используемое в последующей генерации кода удаленного сервиса и подменяющей библиотеки.

[0033] Представленное решение позволяет контролировать аргументы, последовательность и состав вызовов локального API, обеспечивая дополнительный уровень безопасности, изолирующий пользователя. Например, может учитываться количество GPU памяти, выделяемое пользователем через Nvidia CUDA, и не превышая заданный лимит. Также предоставляется возможность управления набором конкретных функций, доступных пользователю.

[0034] Одной из важнейших задач, решаемых в сфере облачных технологий, является организация сервисов, доступных на удаленных узлах. Ограниченное число узлов, предоставляющих доступ к тем или иным ограниченным ресурсам, разделяют между потенциально неограниченным числом пользователей. Прямой доступ на подобные узлы для пользователей чреват множеством проблем в сфере безопасности и отказоустойчивости. Подмножеством данной задачи является сценарий, когда физический доступ к узлу есть, но доступ к конкретному ресурсу нужно давать с модификацией поведения, например, с дополнительными ограничениями.

[0035] Рассмотрим следующий пример: имеется графический процессор (GPU), доступный в единственном экземпляре, и локальный API для его использования. При отсутствии у производителя программно-аппаратных способов делить доступ между пользователями, либо при невозможности по тем или иным причинам приобрести подобное решение, пользователи либо будут вынуждены ждать своей очереди, либо же потенциально влиять на работу друг друга. Кроме того, использование такого устройства будет требовать полноценного физического доступа к узлу, к которому данное устройство подключено.

[0036] Одним из решений подобных проблем является технология удаленного вызова процедур - Remote Procedure Call (RPC). Деятельность пользователя, вместо исполнения напрямую, в виде запросов транслируется в изолированное окружение, зачастую реализованное как сервис. Изолированное окружение может в таком случае, вводя дополнительную программную логику, повлиять на поведение интересующим поставщика ресурсов образом, и лишь потом исполнить штатную реализацию (либо, если требуется, отказать в этом пользователю). Нет никакой необходимости для этого окружения и пользователя ресурса сосуществовать в рамках одного узла; при наличии соединения между узлами, запрос может транслироваться от одного узла другому. Таким образом, можно в рамках ответственного за обработку удаленных вызовов сервиса организовать удаленный доступ к оборудованию, ввести дополнительные уровни абстракции для разграничения полномочий пользователей и решить другие потенциальные проблемы.

[0037] На самом верхнем уровне принцип работы RPC предельно прост и нагляден, и внешне похож либо на вызов обыкновенной функции в рамках того или иного языка программирования, либо же на отправку команды и получение на нее ответа. Детали реализации, включая использование транспортного уровня, обычно остаются за кадром. Данное преимущество обусловило интерес к RPC не только для решения проблем с оборудованием, но и для реализации микросервисных архитектур. Важнейшим преимуществом RPC является иллюзия, будто у пользователей есть физический доступ к интересующим их ресурсам.

[0038] Многочисленные решения в сфере RPC довольно неплохо зарекомендовали себя в случаях, когда конечное решение проектируется с нуля, и есть полный контроль над аспектами реализации как серверной, так и клиентской частями взаимодействия, включая непосредственно штатную логику. Допустим, есть задача спроектировать калькулятор, доступный удаленно, и техническая команда разрабатывает не только протокол взаимодействия пользователей и соответствующего сервиса, но также и полноценно разрабатывает аспекты непосредственно логики вычислений. В таком случае, команда располагает свободой выбора того, как реализовывать серверную и клиентскую части, и может даже при необходимости поменять именно логику вычислений в угоду тем или иным нефункциональным требованиям. Так, например, команда может сконцентрироваться на удобстве разработки, удобстве использования конечным пользователем, простоте сетевого взаимодействия и прочих нефункциональных аспектах.

[0039] Рассмотрим теперь более сложный случай: калькулятор был получен у некоего производителя, вместе с инструкцией в виде некоего API и функциями вида «сложить два числа», «вычесть из одного числа другое» и прочими. Есть необходимость теперь данный калькулятор сделать доступным удаленно. Очевидно, специфика задачи теперь существенно отличается: нужно, по сути, сделать доступным чужое решение, возможно, с рядом своих дополнений, но аспекты реализации данного решения уже не представляется возможным менять. Нужно сделать доступной удаленно «чужую» технологию, для которой уже четко определены и зафиксированы формы локального взаимодействия. Таким образом, технология RPC должна обернуть «чужой» API, который разработчики напрямую не контролируют. Представим, что вместо «калькулятора» фигурирует гораздо более сложная система, в которой гораздо больший функционал, который, помимо прочего, затруднительно использовать удаленно ввиду ряда аспектов реализации. Решению именно этой проблемы посвящается описываемая технология.

[0040] Представленное решение позволяет «обернуть» произвольный существующий и работающий локально API, поставляемый в виде заголовочных файлов, минимизировать временные и производственные затраты за счет частичной автоматизации, а также облегчить переход на новые версии того же API. Данная задача достигается посредством автоматической генерации аналога IDL из заголовочных файлов, адаптации формата IDL именно под задачу «оборачивания» интерфейсов, возможности дополнения сгенерированного кода пользовательским, генерации полноценного кода клиентской и серверной частей вместо заглушек и прочим решениям.

[0041] RPCNG представляет собой достаточно универсальную систему, позволяющую сделать доступными удаленно реализации произвольных интерфейсы от сторонних разработчиков. Тем не менее, среди интересующих нас технологий выделяется широкий срез технологий, способных улучшить масштабируемость и качество облачных услуг. Так, в частности, RPCNG был в первую очередь успешно адаптирован для фреймворка CUDA. RPCNG также обладает большим потенциалом для других решений в сферах машинного обучения и распределенных вычислений. Вместе с тем, хотя данные направления являются наиболее приоритетными, как уже было отмечено, предлагаемое решение может быть адаптировано к любым сторонним интерфейсам и является по своей сути универсальным.

[0042] В соответствии со схемой, приведенной на фиг. 1, система обработки информации содержит соединенные каналами связи по меньшей мере одно устройство 1 пользователя, устройство 1 оператора, по меньшей мере один сервер 10 и устройство 100 поставщика. Каналы связи могут быть реализованы на базе широко известных технологий проводной и беспроводной связи для обеспечения обмена данными.

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

[0044] Сервер 10 может быть реализован известными методами из широко известных вычислительных устройств и оснащен вычислительными ресурсами (BP) 11, например, GPU, CPU, памятью и пр., которые являются удаленными по отношению к устройству 1 пользователя.

[0045] Устройство 100 поставщика может быть реализовано на базе по меньшей мере одного вычислительного устройства и оснащено: модулем 101 управления данными, модулем 102 преобразования структуры данных, модулем 103 генерации конфигураций удаленных вызовов, модулем 104 генерации кода и модулем 105 компиляции. Указанные модули могут быть, например, реализованы на базе логических элементов на транзисторах, размещенные на единой печатной плате.

[0046] Соответственно, если у пользователя устройства 1 возникает потребность в запуске приложения на устройстве 1 с использованием удаленных BP 11, например, GPU, CPU, памяти и пр., размещенных на серверах 10 поставщика услуг, то пользователь посредством устройства 1 направляет запрос на использование BP к устройству 100 поставщика, содержащий ID/название приложения и/или перечень функций, которые следует использовать удаленно для запуска приложения.

[0047] Например, у пользователя может возникнуть потребность в обработке фотографий посредством нейронной сети для распознавания на них объектов или для классификации фотографий с использованием по меньшей мере одного удаленного GPU 11. Дополнительно в запросе на использование BP могут быть направлены данные о интерфейсах (API), которые следует использовать для удаленных BP. Например, данные о интерфейсе (API) могут содержать информацию, описывающую инструкции по обработке данных фотографии устройством пользователя, в частности их преобразовании, для передачи удаленным BP.

[0048] Направленный запрос на использование BP поступает в модуль 101 управления данными, который оповещает оператора устройства 2 о наличии запроса, после чего оператор посредством устройств 2 определяет перечень функционала, подлежащего генерации для доступа к BP удаленно и направляет в модуль 101 сбора данных информацию, описывающую процесс обработки данных посредством BP, которая может быть представлен в виде списка интерфейсов (API), библиотек и функций. Информация, описывающая процесс обработки данных посредством BP, может быть представлена в виде файла локального интерфейса (API) и содержать информацию о типах данных, идентификаторы интерфейсов BP, которые упомянутые типы данных обрабатывают, а также инструкции по обработке данных. Например, файл локального интерфейса (API) может содержать информацию, описывающую функцию перемножения матриц с помощью GPU, в виде программного описания и документации, уточняющей логику реализации.

[0049] После получения информации, описывающей процесс обработки данных посредством BP, т.е. файла локального API, модуль 101 запускает процесс генерации программного кода заменяющих библиотек, предназначенных для обработки данных посредством удаленных BP и программного кода соответствующих сервисов. Для этого модуль 101 направляет упомянутую информацию, описывающую процесс обработки данных посредством BP, которая может быть представлена в виде файла локального интерфейса (API), в модуль 102 преобразования структуры данных, который известными методами преобразует структуру программного кода, описывающего процесс обработки данных посредством BP, в промежуточный код, структура данных которого представляет собой абстрактное синтаксическое дерево (AST) и создает файл AST, в который сохраняется промежуточный код. Данный шаг нужен для эффективной последующей обработки и оптимизации некоторых сценариев сборки (например, параллелизация генерации кода серверной и клиентской частей).

[0050] Далее модуль 102 направляет упомянутый промежуточный код, в частности файл AST, в модуль 103 генерации конфигураций удаленных вызовов, который осуществляет поиск в файле AST информации, описывающей процесс обработки данных посредством BP, и на основе типа данных и правила обработки данных определяет, требуется ли упомянутую информацию включить в файл с конфигурацией удаленных вызовов (RPC). В частности, модуль 103 может быть оснащен БД или программной логикой, содержащей список типов данных и правил обработки данных, с которым сравнивается упомянутая информация, описывающая процесс обработки данных посредством BP, и в случае совпадение типа данных и правила обработки данных со списком модуль 103 осуществляет определение правил передачи данных между клиентом и сервером для обработки данных удаленными BP и формирует файл RPC, в который сохраняется информация о типах данных и правилах их передачи между клиентом и сервером. Упомянутые правила передачи данных между клиентом и сервером могут быть заранее заданы в памяти с программной логикой для каждого типа данных и правил обработки данных.

[0051] Например, тип данных может указывать на то, что информация представляет собой один из типов формата фотографии, например, jpeg, а правила обработки данных могут указывать на то, что на упомянутой фотографии нужно распознать объекты посредством использования GPU. Соответственно, правила передачи данных между клиентом и сервером в файле RPC могут указывать на то, что идентификатор формата «jpeg» следует преобразовывать для передачи в виде последовательности байт [0x00, 0x01], а к значениям данных, характеризующим фотографию (например, значениям яркости), следует добавлять тег с типом данных, также представленный в виде последовательности байт.

[0052] Информация о типах данных и правилах их передачи между клиентом и сервером, сохраненная в файле RPC, может быть отображена оператору устройства 2 для внесения правок с целью дополнить и уточнить логику поведения оборачиваемых функций. Например, могут быть добавлены теги, указывающие на то, что параметры, представленные в файле RPC, являются элементами матрицы, либо могут быть добавлены/скорректированы правила передачи данных между клиентом и сервером.

[0053] Далее модуль 103 направляет файлы AST и RPC в модуль 104 генерации кода, который генерирует код клиента, код сервера и по меньшей мере один набор интерфейсов (API). Для генерации кода клиента модуль 104 извлекает из файла RPC информацию, описывающую правила передачи данных между клиентом и сервером и генерирует код клиента в виде заменяющих библиотек BP, описывающий правила передачи данных от клиента к серверу, а также правила приема данных от сервера. Данные о правилах передачи данных между клиентом и сервером и соответствующий им код клиента могут быть заранее заданы в памяти модуля 104. Например, правила передачи данных от клиента к серверу могут указывать на то, что идентификатор формата «jpeg» следует преобразовывать для передачи в последовательность байт [0x00, 0x01], а правила приема данных от сервера могут указывать на то, что полученную последовательность байт [0x00, 0x01] следует преобразовывать в идентификатор формата «jpeg».

[0054] Для генерации кода сервера модуль 104 извлекает из файла RPC информацию, описывающую правила передачи данных между клиентом и сервером и генерирует код сервера, описывающий правила приема данных от клиента и правила передачи данных от сервера к клиенту. Данные о правилах передачи данных между клиентом и сервером и соответствующий им код сервера могут быть заранее заданы в памяти модуля 104. Например, правила приема данных от клиента могут указывать на то, что полученную последовательность байт [0x00, 0x01] следует преобразовывать в идентификатор формата «jpeg», а правила передачи данных от сервера к клиенту могут указывать на то, что идентификатор формата «jpeg» следует преобразовывать для передачи в последовательность байт [0x00, 0x01].

[0055] В сгенерированный файл с интерфейсами (API) модулем 104 заносится информация о протоколах взаимодействия между клиентом и сервером для передачи между ними данных, например, о протоколе HTTP. Данные о правилах передачи данных между клиентом и сервером и соответствующий им протокол могут быть заранее заданы в памяти модуля 104. Например, для передачи одного типа данных может быть использован один протокол, а для передачи другого типа данных другой протокол, отличный от первого протокола.

[0056] В процессе генерации упомянутого кода клиента или сервера модулем 104 может быть выполнена проверка корректности и целостности данных, извлекаемых из файла RPC. Для проверки корректности и целостности данных модуль 104 может быть выполнен с возможностью извлечения сущностей из файла RPC, и их сравнения с сущностями, извлеченными из файла AST. Для извлечения упомянутых сущностей модуль 104 может быть, например, оснащен нейронной сетью, заранее обученной на размеченной выборке данных, либо сущности могут быть извлечены другим широко известным методом.

[0057] Если при сравнении упомянутых сущностей модуль 104 определил, что сущности, извлеченные из файла RPC, не совпадают с сущностями, извлеченными из файла AST, то модуль 104 прерывает процесс и направляет соответствующее уведомление оператору устройства 100 или устройства 2. Если упомянутые сущности совпадают, то модуль 104 принимает решение о целостности и корректности данных и продолжает генерацию упомянутого кода клиента или сервера описанным ранее методом, после чего сгенерированный код вместе с файлом с интерфейсами (API) направляется в модуль 105 компиляции. [0058] Модуль 105 компиляции при получении упомянутых данных от модуля 104 известными методами выполняет валидацию сгенерированного кода клиента и сервера, после чего извлекает из файла с интерфейсами (API) данные об интерфейсах и добавляет их в код клиента и сервера, таким образом, формируя заменяющие библиотеки и исполняемый файл сервиса, после чего заменяющие библиотеки и исполняемый файл сервиса передаются модулю 101 управления данными, который передает заменяющие библиотеки в устройство 1 пользователя, а исполняемый файл сервиса - на сервер 10, на котором упомянутый файл запускается.

[0059] Заменяющие библиотеки, полученные устройством пользователя, могут быть запущены автоматически после их получения или запуска приложения, либо в ручном режиме по команде пользователя. После запуска заменяющих библиотек пользователь на устройстве 1 может запустить приложение или функцию приложения, требующее задействовать BP, которые могут отсутствовать на устройстве 1 пользователя. Например, пользователь может запустить фоторедактор для обработки фотографии для распознавания на ней объектов или запустить функцию программного обеспечения для распознавания на фотографии объектов.

[0060] Соответственно, после запуска приложения устройство 1 пользователя обращается к библиотекам, запущенным на устройстве 1 вместе с заменяющими библиотеками, в связи с чем команды на обработку данных, предназначенных для BP, преобразуются и перенаправляются в соответствии с правилами передачи данных от клиента к серверу и интерфейсом (API) на сервер 10 для их обработки посредством удаленных BP 11.

[0061] Сервер 10 при получении команд на обработку данных преобразует данные, полученные от устройства 1, в соответствии с правилами обработки данных и интерфейсом (API), после чего результаты обработки данных преобразуются и передаются в устройство 1 в соответствии с правилами передачи данных от сервера к клиенту и интерфейсом (API). Например, сервер 10 может получить от устройства 1 пользователя данные фотографии и команду на распознавание изображения, а в ответ направить данные о распознанных объектах.

[0062] Полученные устройством 1 результаты обработки данных преобразуются в соответствии с правилами приема данных от сервера и интерфейсом (API) после чего результаты обработки данных могут быть сохранены в памяти устройства 1, отображены пользователю на устройствах вывода данных или направлены для дальнейшей обработки. Таким образом, на устройстве 1 пользователя может быть запущено приложение для обработки данных с использованием BP, отсутствующих на этом устройстве 1.

[0063] В общем виде (см. фиг. 2) вычислительное устройство содержит объединенные общей шиной информационного обмена один или несколько процессоров (201), средства памяти, такие как ОЗУ (202) и ПЗУ (203), интерфейсы ввода/вывода (204), устройства ввода/вывода (205), и устройство для сетевого взаимодействия (206).

[0064] Процессор (201) (или несколько процессоров, многоядерный процессор и т.п.) может выбираться из ассортимента устройств, широко применяемых в настоящее время, например, таких производителей, как: Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™ и т.п. Под процессором или одним из используемых процессоров в устройстве (200) также необходимо учитывать графический процессор, например, GPU NVIDIA или Graphcore, тип которых также является пригодным для полного или частичного выполнения способа, а также может применяться для обучения и применения моделей машинного обучения в различных информационных системах. [0065] ОЗУ (202) представляет собой оперативную память и предназначено для хранения исполняемых процессором (201) машиночитаемых инструкций для выполнения необходимых операций по логической обработке данных. ОЗУ (202), как правило, содержит исполняемые инструкции операционной системы и соответствующих программных компонент (приложения, программные модули и т.п.). При этом, в качестве ОЗУ (202) может выступать доступный объем памяти графической карты или графического процессора.

[0066] ПЗУ (203) представляет собой одно или более устройств постоянного хранения данных, например, жесткий диск (HDD), твердотельный накопитель данных (SSD), флэш-память (EEPROM, NAND и т.п.), оптические носители информации (CD-R/RW, DVD-R/RW, BlueRay Disc, MD) и др.

[0067] Для организации работы компонентов устройства (200) и организации работы внешних подключаемых устройств применяются различные виды интерфейсов В/В (204). Выбор соответствующих интерфейсов зависит от конкретного исполнения вычислительного устройства, которые могут представлять собой, не ограничиваясь: PCI, AGP, PS/2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS/Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232 и т.п.

[0068] Для обеспечения взаимодействия пользователя с устройством (200) применяются различные средства (205) В/В информации, например, клавиатура, дисплей (монитор), сенсорный дисплей, тач-пад, джойстик, манипулятор мышь, световое перо, стилус, сенсорная панель, трекбол, динамики, микрофон, средства дополненной реальности, оптические сенсоры, планшет, световые индикаторы, проектор, камера, средства биометрической идентификации (сканер сетчатки глаза, сканер отпечатков пальцев, модуль распознавания голоса) и т.п.

[0069] Средство сетевого взаимодействия (206) обеспечивает передачу данных посредством внутренней или внешней вычислительной сети, например, Интранет, Интернет, ЛВС и т.п. В качестве одного или более средств (206) может использоваться, но не ограничиваться: Ethernet карта, GSM модем, GPRS модем, LTE модем, 5G модем, модуль спутниковой связи, NFC модуль, Bluetooth и/или BLE модуль, Wi-Fi модуль и др.

[0070] Дополнительно могут применяться также средства спутниковой навигации в составе системы (200), например, GPS, ГЛОНАСС, BeiDou, Galileo. Конкретный выбор элементов устройства (200) для реализации различных программно-аппаратных архитектурных решений может варьироваться с сохранением обеспечиваемого требуемого функционала.

[0071] Модификации и улучшения вышеописанных вариантов осуществления настоящего технического решения будут ясны специалистам в данной области техники. Предшествующее описание представлено только в качестве примера и не несет никаких ограничений. Таким образом, объем настоящего технического решения ограничен только объемом прилагаемой формулы изобретения.

Claims (18)

1. Способ генерации удаленных вызовов RPC (Remote Procedure Call), выполняемый по меньшей мере одним вычислительным устройством, содержащий этапы, на которых:

- получают запрос на использование вычислительных ресурсов (BP);

- получают информацию, описывающую процесс обработки данных посредством BP;

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

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

- на основе данных файла RPC генерируют заменяющие библиотеки, описывающие правила передачи данных от клиента к серверу и правила приема данных от сервера, и код сервера, описывающий правила приема данных от клиента и правила передачи данных от сервера к клиенту;

- направляют код сервера на сервер для его запуска на сервере;

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

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

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

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

- извлечение сущностей из файла RPC;

- извлечение сущностей из файла AST;

- сравнение упомянутых сущностей для проверки целостности и корректности данных.

5. Способ по п. 1, характеризующийся тем, что дополнительно содержит этапы:

- извлечения информации о протоколах взаимодействия между клиентом и сервером для передачи между ними данных;

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

6. Устройство генерации удаленных вызовов RPC, содержащее по меньшей мере одно вычислительное устройство и по меньшей мере одну память, содержащую машиночитаемые инструкции, которые при их исполнении по меньшей мере одним вычислительным устройством выполняют способ по любому из пп. 1-5.

Images