Отправка звонков в библиотеки удаленно через Linux

Question

Я занимаюсь разработкой экспериментальной установки на C.

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

У меня есть система A, в которой много приложений.используя криптографические алгоритмы.

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

Поэтому я должен отправлять любые вызовы в криптографический (openssl)двигатели через сокет к удаленной системе (B), которая имеет поддержку openssl.

Мой план состоит в том, чтобы иметь небольшую прогу для сокетов в системе A, которая перенаправляет эти вызовы в систему B.

What I 'В настоящий момент мне все еще неясно, как я обрабатываю полученные команды в Системе B.

Получаю ли я эти команды и транслирую их в соответствующие вызовы openssl локально в моей системе?Это означает, что я должен программировать все, что делается в Системе А, верно?

Или есть способ туннелировать / отправить эти необработанные строки кода непосредственно в библиотеки openssl и только что получить результат, а затем повторно отправить в Систему А

Как, по-вашему, мне следует решить проблему?

PS: Кстати, вызовы криптографии (например, EngineUpdate, VerifyFinal и т. Д. Или дайджест в системе A могут выполняться на Java).или C .. Я уже написал программу на Java / C для отправки этих команд в Систему B через сокеты ... Проблема только в Системе B и как я должен ее обработать ..

Answer 1

Вы можете использовать сокеты на B, но это означает, что вам нужно определить протокол для этого.Или вы используете RPC (удаленные вызовы процедур).

Примеры программирования сокетов можно найти здесь .

Объяснение RPC здесь .

Answer 2

Таким образом, у вас есть два варианта, каждый из которых обозначен соответственно unwind и ammoQ:

(1) Напишите сервер и выполните работу с сокетом / протоколом и т. Д. Самостоятельно.Вы можете минимизировать некоторые трудности, используя такие решения, как буферы протокола Google.

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

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

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

Вы можете пойти по пути RPC с CORBA , ICE или какими-либо решениями Java в наши дни (RMI«EJB») и куча других.Это элегантное решение, поскольку ваши вызовы на удаленный компьютер шифрования отображаются в SystemA как простые вызовы функций, а промежуточное программное обеспечение обрабатывает проблемы с данными и сокеты.Но вы не собираетесь изучать их в выходные дни.

Лично я бы посмотрел, будет ли решение для очереди сообщений, подобное AMQP , работать в первую очередь для вас.Кривая обучения меньше, чем у RPC.

Answer 3

Самый простой (не сказать «легкий», но все же) способ, который я могу себе представить, состоит в следующем:

1. Напишите версии библиотек (прокси), которые вы хотите сделать удаленными.
2. Напишите серверную программу, которая прослушивает вызовы, выполняет их с использованием реальных локальных библиотек и отправляет результат обратно.
3. Предварительно загрузите прокси-библиотеку перед запуском любого приложения, в котором вы хотите это сделать.

Конечно, у этого подхода много проблем:

1. Не совсем тривиально определить протокол сериализации для вызовов функций общего языка C.
2. Также не совсем просто написать сервер.
3. Приложения будут сильно тормозить, поскольку прокси-вызов должен быть синхронным.
4. А как насчет безопасности данных в сети?

UPDATE

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

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

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