Dear associates,


It's not uncommon under *nix to have a "somethingctl(1)" command asssociated with a "something(8)" daemon, so that you can interact with a running daemon to achieve some administration task.

This kind of interface is often (but not necessarily) implemented by means of a UNIX socket, which is what I'd like to use for the little daemon I'm writing.

UNIX sockets are usually[1] nice to work with, but they're somewhat ...raw. Sure, one can implement a parser and just interpret commands in form of strings, but it would be so handy to have some pre-baked protocol for it instead! Something that allows to encode simple commands with parameters.

I searched on the WEBS but it looks like all viable alternatives are either some XML bullshit, or stuff like DBUS.

I never worked with any of them but:

- if there's XML in the name, it must be evil.

- DBUS, where do I start? It comes from freedesktop.org, the "D" stands for Desktop, if the length of the wikipedia is proportional to its complexity, I would not touch it with a stick.

Or zeromq! Which is super nice to work with, but a bit of an overkill in my case, and way too opinionated about event-loops, threading and such.

Well, I'm currently writing a *simple* protocol, with no intention whatsoever of turning it into a stand-alone project later on. But I wonder how other people would have done it.

What would you do in my situation?


[1] Except if you're trying to do something crazy, like sending a file descriptor: the API gets awkward there!


dacav
--- Synchronet 3.18b-Linux NewsLink 1.113

Maybe something like POSIX message queues?

man 7 mq_overview

https://linux.die.net/man/7/mq_overview

Not sure about system compatability, though should be good beyond Linux 2.6.6.

somethingctl over unix sockets

From: Dacav Doe <dacav@tilde.institute>
Reply to: Dacav Doe
Date: Wed, 13 May 2020 11:30:33 -0000 (UTC)
Organization: tilde.club
Newsgroups:
tilde.projects
Followup to: newsgroup
Dear associates,

It's not uncommon under *nix to have a "somethingctl(1)" command asssociated >with a "something(8)" daemon, so that you can interact with a running daemon to
achieve some administration task.

This kind of interface is often (but not necessarily) implemented by means of a
UNIX socket, which is what I'd like to use for the little daemon I'm writing.

UNIX sockets are usually[1] nice to work with, but they're somewhat ...raw. >Sure, one can implement a parser and just interpret commands in form of >strings, but it would be so handy to have some pre-baked protocol for it >instead! Something that allows to encode simple commands with parameters.

I searched on the WEBS but it looks like all viable alternatives are either >some XML bullshit, or stuff like DBUS.

I never worked with any of them but:

- if there's XML in the name, it must be evil.

- DBUS, where do I start? It comes from freedesktop.org, the "D" stands for >Desktop, if the length of the wikipedia is proportional to its complexity, I >would not touch it with a stick.

Or zeromq! Which is super nice to work with, but a bit of an overkill in my >case, and way too opinionated about event-loops, threading and such.

Well, I'm currently writing a *simple* protocol, with no intention whatsoever >of turning it into a stand-alone project later on. But I wonder how other >people would have done it.

What would you do in my situation?

[1] Except if you're trying to do something crazy, like sending a file >descriptor: the API gets awkward there!

dacav

--
https://sdf.org/~lynx/
--- Synchronet 3.18b-Linux NewsLink 1.113

On 2020-05-21, lynx@sdf.org <lynx@sdf.org> wrote:

Maybe something like POSIX message queues?

man 7 mq_overview

https://linux.die.net/man/7/mq_overview

Not sure about system compatability, though should be good beyond Linux 2.6.6.

Thanks for the suggestion.

So far I never used message queues, I always went for UNIX sockets (they're especially nice with SOCK_SEQPACKET).

Not knowing anything on this interface, I had a quick investigation.
For what I learned they look quite similar in principle to UNIX sockets
(that is, they both provide some local "transport" layer), but it seems like message queues are not as popular.

But transport was never a problem in the first place. I would be more interested in some higher level protocol. :)

- dacav
--- Synchronet 3.18b-Linux NewsLink 1.113

I know this response is like, 6 weeks ago! I just joined and am
getting the hang of things. :-)

On 2020-05-13, Dacav Doe <dacav@tilde.institute> wrote:

UNIX sockets are usually[1] nice to work with, but they're somewhat ...raw. Sure, one can implement a parser and just interpret commands in form of strings, but it would be so handy to have some pre-baked protocol for it instead! Something that allows to encode simple commands with parameters.

Years ago, I wrote a shoutcast client daemon (it was a perl script that connected to Shoutcast, and later icecast to play music) doing pretty much what you describe.

All I did was use the shellwords module and parsed the strings myself.

I'd suggest just going bare, maybe using whatever string modules the language you are working with has to offer.

It worked well, and the simplicity of it paid off. Keep in mind that it's
a local socket, if you need to send more data (for example, a playlist
of mp3s to shuffle) you'll likely have the data in a file on the same machine and you'll just need to pass the filename over the socket. So, you won't
likely need to send much complicated data over the socket anyway.

Besides, if you actually did need to, it's a local socket, you can just
connect again in a special mode and send raw data across the wire.

If you load up a complicated protocol library you may end up losing
the simplicity.

Have Fun!

--- Synchronet 3.18b-Linux NewsLink 1.113