我有一个用C编写的简单服务器。它的主要目的是通过专有协议与一些业务合作伙伴进行通信。出于这个原因和其他一些原因，它必须用C语言编写。我有许多其他的过程，但是用其他语言（例如Python）编写，必须与服务器通信（本地，在同一个Linux服务器上）。 / p>
在这种情况下，跨语言IPC的最佳选择是什么？具体来说，我认为我掌握了传输技术：Unix域套接字，命名管道，共享内存，ZeroMQ（Crossroads）。我对实现协议的最佳方式更感兴趣，以保持C代码的小巧和可维护性，同时仍然允许来自其他语言的通信。
编辑：似乎有些混乱。我不对域套接字，共享内存等的利弊讨论感兴趣。人。我我对msgpack感谢（感谢放松），以及其他实现有线协议的技术/方法。
答案 0 :(得分：4)
当需求未知时，很难优化（=选择“最佳”）。你确实声明你的目标是保持C代码“小而且可维护”，这似乎意味着你应该寻找一个库。也许msgpack通过本地套接字？
另外，你的基本前提是服务器必须用C编写，因为你有一个专有协议似乎......很奇怪，至少。
答案 1 :(得分：4)
编辑：你需要的是一个“序列化框架”，即可以将内存结构转换为字节流。最好的候选人是：
优点/缺点：
协议缓冲区
+快速+易于版本（当你第一次需要更改你的信息格式时，你会非常喜欢这个版本，并且在此之前你会诅咒地狱）-解决了许多你不了解的问题。这使得API有点“奇怪”。我向你保证，有很好的理由知道他们做了什么以及如何做，但你有时会感到困惑。我对MessagePack了解不多。
最后：
<强> JSON
+任何语言都可以读写JSON数据。+人类无需工具即可阅读-有点慢-格式非常灵活，但如果您需要进行重大更改，则需要找到一种策略，以便在阅读时确定消息的格式（=哪些字段）。至于传输层：
优点/缺点：
共享内存
+最快的选择-您需要第二个频道（如信号量）告诉其他进程数据现已准备就绪-变得非常丑陋-特定于操作系统命名管道
+很容易设置+相当快-只允许两个进程通话...或者说一个进程可以在一个方向上与另一个进程通信。如果您需要双向通信，则需要多个管道<强>套接字
+很容易设置+适用于所有语言和+允许远程访问（并非所有进程都需要在同一台计算机上）+与一台服务器和多个进程进行双向通信-比shmem和管道慢<强> ZeroMQ
+喜欢套接字，但更好+现代API（不是旧的IPC /套接字垃圾）+支持多种语言...... - ...但不是全部如果您能建议尝试ZeroMQ，因为它是一个现代框架，可以解决您在旧技术中遇到的许多问题。
如果失败了，我接下来会尝试套接字。他们很容易，得到很好的支持和温顺。