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