Межпроцессное взаимодействие C# <-> интерпретатор Lua

Приветствую! Сейчас разбираюсь с задачей управления внешним Windows-приложением с интерпретатором Lua. Это "костыльная" система, альтернатив которой нет, потому не спрашивайте "зачем" - просто "надо". Мне не хватает знаний по организации межпроцессного взаимодействия, потому прошу совета. Сейчас объясню архитектуру и в чём "затыка".

1. Целевое приложение Win64 запускает в дочернем потоке интерпретатора скрипт Lua.
2. Скрипт Lua загружает мою DLL, написанную на C++. Код пишется с использованием статических библиотек разработчика интерпретатора Lua (*.lib, *.h).
3. Управляющее приложение С# должно взаимодействовать с целевым приложением (1) через библиотеку DLL.

Допустим, я реализую в моей DLL базовый механизм двустороннего взаимодействия с целевым приложением. Но сама логика обработки данных целевого приложения не тривиальна и к тому же требует обращения к БД. Поэтому реализовывать весь код на C++ в самой DLL видится крайне неудобным вариантом. Было бы удобно "засунуть" в DLL необходимые интерфейсные методы взаимодействия с целевым приложением, а всю логику вынести в приложение C# (допустим, консольное). Проблема в том, что приложение C# будет работать в одном процессе, а DLL будет загружена целевым приложением в другом процессе, а потому напрямую обратиться к методам в DLL скорее всего не получится. Или есть варианты?

Мне видится необходимым реализовать такие сценарии:
1. Синхронный вызов из приложения C# функции в DLL с возвратом параметров. Для возврата массивов данных можно использовать MemoryFile, заполняемые в DLL.
2. Синхронный обратный вызов из DLL функции в C# с передачей параметров. Для передачи массивов данных использовать MemoryFile, заполняемые в DLL.

Существуют ли разумные способы безопасно реализовать такие сценарии?

PS: Не хотелось бы идти по альтернативному варианту и помещать всю логику в функции в БД, вызываемые из DLL...

0

andreybs1,

Сообщение от Andrey-MSK C++ посылает callback, C++/CLI это обрабатывает и посылает событие, C# это событие ловит и далее по списку.

По тому же пути и данные перекидывать туда-сюда. C++/CLI будет их конвертировать сам в нужные типы.

Добавлено через 4 минуты
andreybs1, Ну и как бы вот такое ещё есть - Embedding Lua in C# Applications: A Comprehensive Guide.

0

У него Lua уже встроен во враждебное приложение. Зачем ему встраивать Lua ещё раз?

0

Сообщение от Tupiel Reuschin 1) у вас есть немодифицируемое чужое приложение (хищников, капиталистических). Это требование, интегрироваться с ним. 2) у вас есть возможность загрузить туда .dll

Так точно.

Сообщение от Tupiel Reuschin Надо объяснить, почему нужен второй процесс. Или для чего. Или зачем.

Либо я что-то не понимаю, либо... Ну, смотрите.
1. "Капиталистическое приложение" загружает dll в свой процесс путём запуска внутри себя скрипта lua с командой reqire('mylib.dll'). Это независимое адресное пространство в одном процессе.
2. Управляющее приложение запускается в своём отдельном процессе и ""слушает"/пинает" dll. Это другое адресное пространство в другом процессе.
Вроде всё просто и однозначно. Есть варианты?

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

Именно так. Шаред мемори планирую использовать для того, что серриализовать нельзя. Json всем хорош, главное чтобы не тормозил сильно. Текст всё таки.

Сообщение от Wolfdp Ну такое. Лучше иметь один канал связи, и передавать кусками данные в него, чем плодить 100500 каналов.

Мне не очень понятно, как можно совместить json и несерриализуемые данные в одном канале.

Сообщение от Andrey-MSK А зачем вам нужен сам интерпретатор? Он ведь уже загрузил вашу DLL и она работает с чужим ПО напрямую.

Ну он как бы и не нужен в контексте описанной задачи. Его задача только подгрузить dll (метод lua require) в контекст управляемого приложения.

Сообщение от Andrey-MSK C++ посылает callback

Как посылает? Куда? Можно подробнее? Если есть пример кода или статья, будет понятнее...

Сообщение от Andrey-MSK Ну и как бы вот такое ещё есть - Embedding Lua in C# Applications: A Comprehensive Guide.

Изучу. Спасибо.

Сообщение от alecss131 Не понимаю зачем обертка на С++ над С dll

Ещё одна интерпретация понимания задачи... )))
Нет там никакой обертки "С++ над С dll"...

Добавлено через 38 секунд

Сообщение от Tupiel Reuschin У него Lua уже встроен во враждебное приложение. Зачем ему встраивать Lua ещё раз?

Кто сказал, что его надо встраивать ещё раз? )

0

Сообщение от andreybs1 Мне не очень понятно, как можно совместить json и несерриализуемые данные в одном канале

Какие данные у вас не получается сериализировать?

0

Сообщение от Wolfdp Какие данные у вас не получается сериализировать?

Допустим, бинарные данные. Как-то не очень хочется их в json упаковывать. Но пока это не супер большая проблема. Идея с json в целом меня устраивает.

0

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

А в целом, тут прослеживается, условно, два процесса с общим ресурсом. Оба приложения могут читать/управлять этим ресурсом, а сам ресурс должен понимать и уметь общаться с обоими клиентами. Ну и разрешать конфликты, разумеется.

0

Сообщение от andreybs1 Допустим, бинарные данные. Как-то не очень хочется их в json упаковывать.

используйте не json, а protobuff. Или любую другую бинарную сериализацию.

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

0

Сообщение от Andrey-MSK andreybs1, Ну и как бы вот такое ещё есть - Embedding Lua in C# Applications: A Comprehensive Guide.

Тут про другое. Наверное, проще нарисовать, что нужно мне...



Специально пронумеровал, чтобы обращаться к блокам на схеме.
1-2-3 уже есть, это нельзя изменить.
4 я могу написать, используя стандартные библиотеки lua.lib
6 и 7 уже написано мною для другой задачи
предполагается доработать 6 для взаимодейтсвия с 5

0

Сообщение от wizard41 Столько много слов, а суть так и не ясна

Вы правы, пора схему рисовать. )
см.выше

Добавлено через 2 минуты

Сообщение от Wolfdp используйте не json, а protobuff

Спасибо за подсказку. Поищу подходящую реализацию, чтобы были удобные библиотеки на C++ и C#

0

andreybs1, ну вот теперь яснее выглядит. Правда, к шарпу вопрос относится поверхностно: внедрить плюсовые сборки в код C# не проблема. Основная работа будет в модуле "5" на C++, создать соотв. события и методы для шарпового приложения. Ну и описать структуры передаваемых данных, чтобы обоим были понятны..

0

а 2-3 это сервис, или обычное десктопное приложение? Если подразумевается что "запустили основное приложение и тут же появилось наше C# приложение", я бы тоже рассматривал возможность инжекта в сам процесс, а не стороним процессом. Если нужно независимо крутящееся приложение, и возможность подключиться стороним приложением через контракт в dll -- вроде ок.

0

Сообщение от Wolfdp через контракт в dll -- вроде ок

Через контракт спокойно, я так читы для сетевых игр делал.. Через LUA как раз.

0

Сообщение от wizard41 Через контракт спокойно, я так читы для сетевых игр делал..

Дык игры же и есть "десктопное приложение".

Я к тому что если 2-3 -- часть какого-то фонового сервиса, то задум с межпроцессорным взаимодействием имеет смысл.

0

Wolfdp, ага, просто LUA - скриптовой движок и довольно старый, начал "пропадать" примерно в 2008-10х годах. Давноооо его не встречал в игровых механиках и тем более в других приложениях.

Добавлено через 7 минут
andreybs1, я инжектился к LUA напрямую с помощью AutoIt. Это тоже скриптовый язык, но весьма продвинутый - в том числе тоже юзает механизмы .NET.
В мои годы он довольно серьезно развивался. На данный момент не могу сказать что с ним, давно не наблюдаю. Точно скажу, что на нем перехват системных сообщений, драйверов, мышек-клав, флешек - делалось на раз-два.

0

Сообщение от wizard41 Основная работа будет в модуле "5" на C++, создать соотв. события и методы для шарпового приложения. Ну и описать структуры передаваемых данных, чтобы обоим были понятны..

Именно так. Учитывая, что шарп и dll живут в разных процессах. И сделать это максимально красиво, без лишнего "колхоза".

Сообщение от Wolfdp а 2-3 это сервис, или обычное десктопное приложение?

Обычное пользовательское приложение, взаимодействующее с сервером 1. К этому приложению нужно "подселить" мой фоновый процесс, по сути имитирующий работу пользователя по взаимодействию с сервером 1 и не мешающий основной работе пользователя.

Сообщение от Wolfdp Если подразумевается что "запустили основное приложение и тут же появилось наше C# приложение", я бы тоже рассматривал возможность инжекта в сам процесс, а не стороним процессом.

Вообще управляемое приложение 2 должно работать независимо. Но вопрос инжекта в его процесс я бы мог рассмотреть, как вариант. Хотя мне кажется, что встроенный интепретатор не вытянет по ресурсам. Всё-таки большая программа на шарпе (напомню, там и нейросетки организованы и в БД оно лазиет постоянно) и компактная dll на c++ (реализующая лишь интерфейс передачи данных и управления) - не одно и то же. К тому же мы снова упрёмся в вопрос дебага. Когда шарп отдельно, а dll отдельно, то легко собрать тестовый стенд из обычного внешнего интерпретатора lua. А когда всё сшито в один процесс, запускаемый из неуправляемого кода, то мне с трудом верится, что это можно нормально дебажить. А как именно вы бы предложили запустить приложение C# в том же процессе, что и C++ DLL, подгружаемая встроенным интерпретатором lua?

Добавлено через 2 минуты

Сообщение от wizard41 Точно скажу, что на нем перехват системных сообщений, драйверов, мышек-клав, флешек - делалось на раз-два.

Мне это не понадобится. )
Там связка 2-3 весьма специфичная. Там как бы lua, но реализующий связку с объектной моделью приложения 2. Типа "правильный" lua. ) Его ценность как раз в доступе к объектной модели приложения 2, а не в инжекте всякими псевдохакерскими средствами и перехвате чего-то там. Всё итак доступно и даже официальная документация есть. Эту систему хакнуть даже при желании сходу не получится, т.к. там сложное шифрование на каждом шагу. Но идея с AutoIt прикольная. )

0

Сообщение от andreybs1 Либо я что-то не понимаю, либо... Ну, смотрите. 1. "Капиталистическое приложение" загружает dll в свой процесс путём запуска внутри себя скрипта lua с командой reqire('mylib.dll'). Это независимое адресное пространство в одном процессе.

Да, давайте смотреть.
1.а) "Капиталистическое приложение" ... это независимое адресное пространство в одном процессе.
1.б) "Капиталистическое приложение" загружает dll в свой процесс ... reqire('mylib.dll')

Этого в принципе достаточно для того, чтобы в mylib.dll запустить шарповый код из блока 6 в картинке. Сам блок 6 надо будет немного перепилить из консольного .exe в управляемую .dll, но она-то ваша и модифицруемая, так что это не страшно.

Сообщение от andreybs1 2. Управляющее приложение запускается в своём отдельном процессе и ""слушает"/пинает" dll. Это другое адресное пространство в другом процессе.

А зачем, почему, управляющее приложение запускается в своём отдельном процессе? Что мешает запустить его из lua-скрипта из интерфейса программы 2 с картинки?

0

Сообщение от andreybs1 Учитывая, что шарп и dll живут в разных процессах.

Вы же знаете что такое DLL?

DLL — это библиотека, содержащая код и данные, которые могут использоваться несколькими программами одновременно.

В DLL пишете функции с callback, которые работают с вашим вражеским приложением, потом прокидываете этот callback в C#.

Добавлено через 1 минуту
Или я что-то не так понял...

0

Мне сложно сказать насколько связка C++, Lua, C# сложна в дебаге, по єтому пункту решать исключительно вам с оглядкой на совет знающих.

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

Тем не менее вариант дочернего процесса + пайплайн -- норм. Причём можно сделать так:

- используем анонимные каналы, которые разрешают доступ только дочерним процессам
- dll точке входа создает два сервера: один на write, другой на read
- запускаем дочернее приложение и в аргументах передаем дескрипторы
- дочернее приложение запускает у себя соответсвующие клиенты.
- обмен сообщениями через json/protobuff. В идеале нужен отдельный проект, который будет содержать только описание моделей (для protobuff это вроде текстовые файлы описывающие поля), и на основе их проекты C#/C++ будут генерить автокод с моделями.
- сам код C# программы стоит хранить в dll качестве ресурсов или чтобы C++ либа ссылалась на неё. Это гарантирует что вы будете ссылаться на правильную сборку, и не случится ситуации что запускаете старую программу.
- анонимные каналы будут гарантировать что только дочерний процесс получит доступ к данным текущего процесса. А значит если вдруг в одном окружении нужно запустить два экземпляра основной программы -- ноль проблем.

Возни в таком подходе больше, но меньше головной боли при сопровождении кода. Поменяли структуру передаваемых данных -- билд -- сразу увидили ошибки, а не "там новое, там старое, падает в рандомном моменте". Билд подразумевает на выходе одну C++ либу, которая содержит в себе C# программу, что избавляет от "там поменял, там забыл". Всегда меняем всю C++ либу. Анонимные каналы сложнее в том плане что не позволяют работать двунаправленно или по сети, но гарантируют изоляцию.

0

Сообщение от Tupiel Reuschin Этого в принципе достаточно для того, чтобы в mylib.dll запустить шарповый код из блока 6 в картинке.

Не совсем. Мне нужно сохранить возможность обращения из функций DLL к объектной структуре "капиталистического приложения". Сейчас это возможно благодаря интерфейсной С-библиотеке lua.lib от разработчика, на базе которой собирается DLL. Т.е. чтобы запустить шарп в одном процессе с "капиталистическим приложением" нужно либо иметь аналогичную библиотеку разработчика на шарпе (а не на C), либо таки сделать dll на C++ и уже из неё подгрузить dll, полученную из моего приложения C#, собранного в виде dll, а не exe. Я правильно понял ваше предложение?

Главный вопрос вызывает процесс дебага кода, написанного на шарпе в таком варианте. А кода там много. И дебаг нужен именно в контексте взаимодействия "капиталистического приложения". Тут надо подумать.

Сообщение от Tupiel Reuschin Что мешает запустить его из lua-скрипта из интерфейса программы 2 с картинки?

У меня большие сомнения в том, что если так сделать, то это не нарушит производительность "капиталистистического приложения". Подвисания, утечки памяти, тяжёлые вычисления и обращения к БД через всякие npgsql. Тут надо тестировать. Просто не хотелось бы обламаться в ходе нагрузочного тестирования, когда всё это напишешь таким вот образом.

Добавлено через 2 минуты

Сообщение от Andrey-MSK Или я что-то не так понял...

dll -это просто шалон кода. Одна и та же dll, подгруженная в разные процессы, не означает коммуникацию между ними. Вопрос инжекта в один процесс обсуждается выше.

Добавлено через 9 минут

Сообщение от Wolfdp Билд подразумевает на выходе одну C++ либу, которая содержит в себе C# программу

Поясните, что здесь имеете ввиду... Проект на C++ собирается в dll. А как предполагается включить в состав этой dll программу на C#?

0

Сообщение от andreybs1 сделать dll на C++ и уже из неё подгрузить dll, полученную из моего приложения C#, собранного в виде dll, а не exe. Я правильно понял ваше предложение?

Да, правильно. При загрузке DLL на C++ она инициализирует рантайм CLR, грузит управляемую .dll #6, выходит (обратно в Lua).
Затем Lua вызывает этот ваш C++, C++ прокидывает вызов в управляемую DLL через P/Invoke колбэк.
Можете вашу .lib прилинковать к вашей C++ .dll-библиотеке, это никак не влияет.
Из C# кода тоже можно вызывать C++ и оттуда попасть в этот .lib статически прилинкованный, а затем вернуться в C#.

Добавлено через 1 минуту

Сообщение от andreybs1 Главный вопрос вызывает процесс дебага кода

Запускаем капиталистическую прогу, грузим .dll в память из Lua. Аттачимся к процессу отладчиком, ставим точку останова, запускаем основной рабочий вызов, выпадаем в отладчик, отлаживаем C# код. Как быть с остальным кодом - я не знаю.

Добавлено через 5 минут

Сообщение от andreybs1 сомнения ... нарушит производительность

Скорее не производительность, а "надёжность". С точки зрения надёжности капиталистическая программа написана великими программистами безошибочно, а ваша - бажная, и вы боитесь, что будет ронять процесс.
Ну, собственно и что? Почему это плохо?

В C# есть фреймворки для плагинов, их несколько разных. Есть MAF - самое сложное и зубодробительное решение из всех, которые я видел. Зато позволяет принять решение о том, проводить запуск в отдельном процессе или в том же при помощи конфигруирования после деплоймента.
То есть, немножко шарпа внутрь, весь остальной снаружи, и всю коммуникацию писать на шарпе. Обоснование - любимый язык.

0