我有一个现有的C过程，可以接受一个文本输入并生成一个图像文件。 这个C进程由于与外部系统的接口而具有很高的设置/拆卸成本。 一旦发生设置/拆卸，实际从文本生成图像几乎是瞬间的。在长期运行的c进程和python之间进行双向IPC的最佳方式是什么？
我的计划是对C进程进行守护进程，因此它将在无限循环中接收文本并生成图像文件，同时保持与外部系统的连接。
我还将在python中编写一个小型客户端程序，它将与守护程序接口发送文本/接收图像。
目标操作系统是unix。
问题是，在这种情况下，在python/C之间执行双向IPC的最佳方式是什么？ 我应该打开一个unix域套接字并来回发送打包结构，还是应该看看Apache Thrift或protobuf之类的东西？
UPDATE：
只是要保持它的简单，并打开一个UNIX域套接字
插座是我想去的地方。在Unix上，我会推荐AF_UNIX套接字（请参阅unix(7)联机帮助页）。这些很容易在C++和python中创建（sockets模块）。这可以避免端口冲突问题或在本地系统上打开端口的权限问题。
如果您决定与远程工作人员合作，Unix套接字执行得相当好，并且可以轻松地将其替换为AF_INET6套接字。
对于打包/解包数据，使用compiled Struct objects的struct模块对我来说似乎是合理的。这就是我过去的表现，而且表现相当好（没有采取任何措施，因为对我来说这太好了）。
+1，但我不认为stdin/stdout管道对于Python客户端启动后连接的守护进程是可行的。 –
是的，我同意使用Unix域套接字有很多优点。 我同意斯文的观点，我不认为你对管道的陈述是有道理的。 此外，你没有触及所有关于通过套接字传输数据的方法，一旦它被打开（我提到使用'struct'模块的打包结构） – jdeuce
@python_noob好的，我没有读过它C进程将始终处于后台，并且不会由Python进程开始deamonized。在这种情况下，管道是无稽之谈。 'struct'对我来说很好，这就是为什么我没有明确提到它，我会在一分钟内纠正它。 –
我默认的选择是使用普通的套接字通信的本地主机。套接字是一个很好理解的语言和平台中立的API，它们往往表现得非常好。他们还有一个好处，就是不会将您绑定到同一个箱子上的两个过程，这在许多情况下都是有利的。
我知道这是常见的，但我的经验是，这有非常糟糕的结果。它会导致代码中的安全问题不应该是网络可访问的，无论是意外地让外部世界与您的程序对话并让不可信用户与之交谈。它也遭遇命名空间问题，因为您可能会选择与其他人相同的端口号。最后，使用端口号，而不是理智的路径，只是尴尬。 – timthelion
我会去做最简单的解决方案。在文件系统中的某个知名位置可能有一对命名管道是最少麻烦的。你只需要处理标准的文件命令。 –
是的，你应该做出这个答案，所以我可以接受它 – jdeuce