私はCで書かれた単純なサーバーを持っています。それの主な目的は、独自のプロトコルを介していくつかのビジネスパートナーと通信することです。その理由と他のいくつかの理由から、Cで記述する必要があります。他にも多くのプロセスがありますが、サーバー（ローカルでは同じLinuxサーバー上）と通信する必要がある他の言語（Pythonなど）で記述されています。
このシナリオでのクロスランゲージIPCの最良のオプションは何ですか？具体的には、Unixドメインソケット、名前付きパイプ、共有メモリ、ZeroMQ（Crossroads）などのトランスポートテクノロジを理解していると思います。他の言語からの通信を可能にしながら、Cコードを小さく維持しやすくするために、プロトコルを実装するための最良の方法にもっと興味があります。
編集：いくつかの混乱があるようです。ドメインソケット、共有メモリなどの長所/短所についての議論には興味がありません。al。msgpack（unwindに感謝）、およびワイヤープロトコルを実装するための他のテクノロジー/アプローチに興味があります。
It's hard to optimize (=select the "best") when the requirements are unknown. You do state that your goal is to keep the C code "small and maintainable", which seems to imply that you should look for a library. Perhaps msgpack over a local socket?
Also, your basic premise that the server must be written in C because you have a proprietary protocol seems ... weird, at least.
編集：必要なのは「シリアル化フレームワーク」です。つまり、何かがメモリ構造をバイトストリームに変えることができます。最適な候補は次のとおりです。
長所短所：
プロトコルバッファ
+速い+バージョン管理が簡単（初めてメッセージ形式を変更する必要があるときに非常に気に入るはずであり、その前に地獄に呪うでしょう）-あなたがまだ知らない多くの問題を解決します。そのため、APIは少し「奇妙」になります。私はあなたに保証します、彼らがそれを何をどのように行うかについては非常に正当な理由がありますが、あなたは時々混乱するでしょう。MessagePackについてはよくわかりません。
最後に：
JSON
+そこにあるどの言語でもJSONデータの読み取りと書き込みができます。+ツールなしで人間が読める形式-やや遅い-形式は非常に柔軟ですが、大きな変更を加える必要がある場合は、メッセージを読んだときにメッセージの形式（=どのフィールド）を把握するための戦略を見つける必要があります。トランスポート層について：
長所短所：
共有メモリ
+最速のオプション-データの準備ができたことを他のプロセスに通知するには、2番目のチャネル（セマフォなど）が必要です。-2つ以上のプロセスを接続しようとすると、本当に醜くなります-OS固有名前付きパイプ
+セットアップがとても簡単+かなり速い-2つのプロセスのみが通信できるようにします...つまり、1つのプロセスが1つの方向で別のプロセスと通信できるようにします。双方向通信が必要な場合は、複数のパイプが必要ですソケット
+セットアップはとても簡単です+すべての言語で利用可能+リモートアクセスを許可します（すべてのプロセスが同じマシン上にある必要はありません）+1つのサーバーと複数のプロセスとの双方向通信-shmemやパイプよりも遅いZeroMQ
+ソケットのようですが、より良い+最新のAPI（古いIPC /ソケットジャンクではありません）+多くの言語のサポート...-...すべてではありません可能であれば、ZeroMQを試してみることをお勧めします。これは、古いテクノロジーで発生する問題の多くを解決する最新のフレームワークだからです。
それが失敗した場合は、次にソケットを試してみます。彼らは簡単で、よくサポートされ、従順です。