用于基于 C 的远程控制/守护进程 (IPC/RPC) 的优雅 API？

发布于 2024-09-30 13:15:46 字数 790 浏览 10 评论 0原文

我有一个守护进程（必须用 C 语言编写），它应该有一个像普通媒体播放器一样的遥控器：

mediaplayer-rc --enqueue /path/to/song.mp3

如果 mediaplayer-daemon 没有运行，它由遥控器启动。遥控器将传递消息。

我采用了对我来说最直观的方法：

客户端应用程序尝试 connect() ，如果无法连接则启动守护进程
客户端使用 argp 将参数解析为结构体
客户端发送通过套接字
服务器接收结构并解释它

我有一个 github 上使用 libev 和 unix 套接字的简单演示实现。

我的理由是，用 C 语言编写一个客户端，我可以使用其他语言的 system() 版本来调用它，这似乎比尝试使用另一种语言来 pack 更容易。正确的结构或让 C 库解析其他格式。

但我不认为这是一个特别优雅的解决方案。

另一种可能性是使用 JSON。缺点是在 vanilla C 中使用 JSON 解析器可能比 args 解析器更复杂。结果是 JSON（或 YAML）出现在几乎所有其他语言的标准库中。

有什么建议吗？有人知道songbird、gimp、itunes 和其他带有遥控器的应用程序如何处理这个问题吗？

原文

I have a daemon (which must be written in C) which should have a remote like common media players do:

mediaplayer-rc --enqueue /path/to/song.mp3

If mediaplayer-daemon isn't running, it is started by the remote controller. The remote will pass the message.

I took the approach that seemed the most intuitive to me:

The client application tries to connect() and starts the daemon if it can't
The client uses argp to parse the params into a struct
The client sends the struct through a socket
The server receives the struct and interprets this

I've got a simple demo implementation using libev and unix sockets on github.

My reasoning is that it seemed easier to write a client in C that I can call from other languages with their version of system() than to try to get another language to pack the struct correctly or to get the C library to parse some other format.

But I don't think that this is a particularly elegant solution.

Another possibility, would be to use JSON. The downshot being that using a JSON parser in vanilla C would probably be more complex by far than the args parser. The upshot being that JSON (or YAML) is in the standard libraries of just about every other language.

Any suggestions? Anybody know how songbird, gimp, itunes, and other apps with remotes handle this issue?

分享到QQ

分享到微博