我目前正在从事一个项目，该项目需要在“主”进程的控制下运行多个进程，该进程通过 TCP 接收远程命令并告诉子进程要做什么（例如：他们应该处理哪些文件，哪些处理操作他们应该执行）。
我想出了以下想法将命令/配置传递给子进程：
- 信号（不够强大）
- 通过套接字或管道将每个进程连接到主进程的二进制协议（重新发明轮子）。
- RPC（也许矫枉过正）
- CORBA（也许是矫枉过正）
- DDS（完全矫枉过正）
有什么想法/建议吗？
问问题
1223 次
5 回答
1
于 2010-12-02T18:42:23.990 回答
0
supervisord工具可能很有用。这是一个客户端/服务器系统，允许其用户监视和控制类 UNIX 操作系统上的许多进程。
于 2012-02-10T13:53:00.357 回答
0
通过管道的文本协议怎么样？
文本协议总是比二进制协议更好，因为它们更容易测试，更容易测试通常意味着更少的错误。
于 2010-12-02T23:02:27.740 回答
0
您还可以使用消息队列或带有信号量的共享内存。
您还可以查看一个名为 ActiveMQ 的 Apache 项目，该项目允许将消息分派到订阅队列等。它非常强大和灵活，并且有 C 接口。如果您有许多需要向其发送消息的机器/网络，这是理想的选择。
于 2010-12-03T00:18:05.633 回答
0
像 beanstalkd 或 resque 这样的轻量级消息队列似乎是正确的复杂程度。带有 inotify 的文件也可以工作；inotify 被设计为一个事件队列。您可以在烘焙之前使用 incrontab 尝试它。{xml,json}-rpc （稍微）更复杂，但也更标准，因为它们使用 http。但是，对于非阻塞交互，消息队列隐喻比 rpc 更合适。
于 2010-12-03T01:29:18.847 回答