我正在用C开发一些实验装置。
我正在探索如下方案，我需要帮助来理解它。
我有一个系统A，它有很多使用加密算法的应用程序。
但是这些加密调用（openssl调用）应该发送到另一个负责加密的系统B。
因此，我必须通过套接字将任何对加密（openssl）引擎的调用发送到具有openssl支持的远程系统（B）。
我的计划是在系统A上安装一个小插槽，它将这些调用转发给系统B.
目前我还不清楚我是如何处理系统B收到的命令的。
我是否真的得到这些命令并将它们转换为在我的系统中本地对openssl的相应调用？这意味着我必须对系统A上所做的任何事情进行编程吗？
或者有没有办法将这些原始代码行直接隧道传送到openssl libs，只是收到结果然后重新发送到System A
您认为我应该如何解决这个问题？
PS：哦顺便说一句，对加密的调用（如EngineUpdate，VerifyFinal等或系统A上的摘要可以是Java或C ..我已经编写了一个Java / C程序，通过这些命令将这些命令发送到系统B插座... 问题仅出在系统B以及我必须如何处理..答案 0 :(得分：1)
答案 1 :(得分：0)
我能想象的最容易的（不是说“简单但仍然”）方式是：
当然，这种方法存在很多问题：
<强>更新：
根据评论的要求，我会尝试扩展一下。 “包装器”是指一个新库，它具有与另一个相同的API，但实际上并不包含相同的代码。相反，包装器库将包含用于序列化参数，调用服务器，等待响应，反序列化结果以及将它们呈现给调用程序的代码，就像没有发生任何事情一样。
由于这涉及许多繁琐，重复且容易出错的代码，因此最好通过使代码驱动来抽象它。最好的方法是使用原始库的头文件来定义所需的序列化，但（当然）需要非常繁重的C解析。如果做不到这一点，您可以自下而上并使用自定义语言来描述调用，然后使用它来生成序列化，反序列化和代理代码。
在Linux系统上，您可以控制动态链接器，以便加载代理库而不是“真实”库。您当然也可以用代理替换（在磁盘上）真实的库，但如果服务器不工作，这将破坏使用它的所有应用程序，这似乎非常危险。
答案 2 :(得分：0)
所以你基本上有两个选择，每个选择分别由unwind和ammoQ概述：
（1）自己编写服务器并执行套接字/协议工作等。您可以使用Google's protocol buffers.
等解决方案来减少一些痛苦（2）使用现有的中间件解决方案，如（a）消息队列或（b）RPC机制，如CORBA及其许多替代方案
要么可能比你预期的更多的工作。所以你真的必须自己回答这个问题。你的项目有多严重？你的硬件多么多样？未来硬件和软件配置有多大可能发生变化？
如果这不仅仅是一个学习或宠物项目，你将在一两个月内感到厌倦，那么现有的中间件解决方案可能就是这样。缺点是有一种有点令人生畏的学习曲线。
您可以使用CORBA，ICE或者最近的Java解决方案（RMI？EJB？）以及其他一些来实现RPC路由。这是一个优雅的解决方案，因为您对远程加密机器的调用对您的SystemA来说是简单的函数调用，中间件处理数据问题和套接字。但是你不打算在周末学习它们。
就个人而言，我会查看像AMQP这样的消息队列解决方案是否适合您。学习曲线比RPC少。