I want to implement a Unix daemon (let's call it myUnixd), and want the user to be able to interact with this daemon via the command line, for example:
myUnixd --help # will display help information
myUnixd --show # will show some data (the's deamon should be doing the work)
So my question is: How can I communicate with the daemon? I was thinking about Unix domain sockets. Can someone tell me the right way to do this?
Thanks.
Use Berkeley sockets. Specifically, you can create a "UNIX domain socket" (otherwise known as a "local domain socket," which will create what looks like a text file. Write to the text file to send text to the daemon, read from it to receive text from the daemon. You can implement this with a few function calls.
If you want something more advanced, you can also use DBus, which offers a more sophisticated interface, but which is more complicated to learn.
use tcp socket if you want to use telnet to communicate with your daemon.
One could also use Remote Procedure Call (RPC) for such client-server communication. There are different types of messages (protocols) that can be used together with it, one of them is JSON.
The JSON-RPC protocol is very well accepted for such tasks. You can find different tools and libraries to embed in your software. A quick search on google gives this C library. The advantage of such libraries is that from a JSON specification file, where you define all your remote function calls, it creates client and/or server stubs that you can just use in your code out of the box.
As a listener one can use sockets, as the other responses state, or just an embedded HTTP server like microhttpd (and libcurl for the client). There are plenty of examples out there to just reuse. HTTP allows you also to run your client behind a proxy.
Related
I made a simple webserver in C now with config implementation. Now, I want to add feature to manage server by calling same process with command line arguments. Like Nginx for example: nginx -s reload will send signal to server and it will reload config from file. I want to achieve the same. But how? In Linux, I can send a signal to server master process by getting PID from pidfile. But how to make it in Windows? Or maybe there is another way?
You can listen on a fixed port number with loopback interface for IPC. There are many cross-platform libraries like libuv and nanomsg.
--
Another method is to use some abstraction provided by a library. For example, still libuv and nanomsg. (Both use domain socket on Unix and named pipes on Windows.)
I have a need to provide restful api support to a linux deamon process that will maintain and manipulate a in-memory table (simple C structure of arrays). This deamon will act as a configuration entity and will relay the table contents to another process on its bootup or during configuration request.
Now in this context i would be happy to obtain the following information:
Would it be good to have an integrated web server or have an independent web server and talk to this daemon. Please note this server would not be required to handle huge loads.
Please suggest some good web servers with good REST support.
If an independent web server then what is the best mechanism for web server to deamon communication.
Please note this would be deployed on a small embedded board running debian.
Well, a possible solution is based on developing a CGI that is executed by any webserver (apache, lighttpd, ...) . This program connects to the main daemon with an IPC mechanism such as sockets, fifos or message queues and after interacting with the daemons returns the desired output to the REST client.
The CGI program can be written in any language, but if you want to write it in C, check this project: it's a CGI program written in C that takes commands for an IP camera. The connection with a main daemon is not implemented, since it was outside the scope of the project. I like it because it has an embedded XML parser and does not require any external library
Do you know of any HTTP client library in C (with SSL support) that also allows direct communication with the remote server?
I have a client-server application where the client uses HTTP to start a session in the server and then tells the server to switch the connection from HTTP to a different protocol. All communication is encapsulated in SSL. It is written in Perl and works well, but I'm looking into implementing the client in C.
I know libcurl gives you access to the underlaying socket but it's not enough because of the SSL requirement.
Notice that libcurl doesn't do the SSL part by itself, it uses OpenSSL. So, if you can get the socket handle from libcurl after the first HTTP interactions, AND the session key it uses (some spelunking required) you can go on directly with OpenSSL from that point.
I think that you must be looking for this otherwise you must have to write it yourself, like this
Sounds like you want Web Sockets. Don't know if there's a C library available though. I would assume there is, if you dig.
I am using C language and Linux as my programming platform.
I am developing a user-space application that runs in a background, like a daemon. And my problem is, I want another user-space application to communicate with this daemon.
I know that I have to use Interprocess Communication method but I don't know what is the correct implementation.
But using IPC in my communication implementation is my other option. Actually I just want to change the attribute of my daemon by using another application. Please see below a senario:
My daemon runs in a background.
Then some application will control the properties of a daemon, like sleeping delay time.
My first option is by accessing a file with the values of the properties. So that my deamon will poll that values. While the other application will change that values.
I am not sure the efficiency of my options. Please advice.
THanks.
Updating the config file and sending a signal to cause re-read is a standard practise, cheap and easy.
You're looking for D-Bus. Store the initial values in a file, then listen over D-Bus for requests to change it.
Unix domain sockets are a simple IPC method.
If I were you, I'd forego IPC completely and instead have the daemon monitor a config file for changes. IPC is only really needed if you're going to be sending thousands of messages per second and the overhead would get intolerable.
inotify is an option for file monitoring.
I'd make the daemon listen on a pipe/fifo if it's simple enough that you only need to read a couple of bytes fed in from another program. Otherwise a local domain socket is nice to run a simple protocol over.
The user, administrators and support staff need detailed runtime and monitoring information from a daemon developed in C.
In my case these information are e.g.
the current system health, like throughput (MB/s), already written data, ...
the current configuration
I would use JMX in the Java world and the procfs (or sysfs) interface for a kernel module. A log file doesn't seem to be the best way.
What is the best way for such a information interface for a C daemon?
I thought about opening a socket and implementing a bare-metal http or xmlrpc server, but that seems to be overkill. What are alternatives?
You can use a signal handler in your daemon that reacts to, say USR1, and dumps information to the screen/log/net. This way, you can just send the process a USR1 signal whenever you need the info.
You could listen on a UNIX-domain socket, and write regularly write the current status (say once a second) to anyone who connects to it. You don't need to implement a protocol like HTTP or XMLRPC - since the communication will be one-way just regularly write a single line of plain text containing the state.
If you are using a relational database anyway, create another table and fill it with the current status as frequent as necessary. If you don't have a relational database, write the status in a file, and implement some rotation scheme to avoid overwriting a file that somebody reads at that very moment.
Write to a file. Use a file locking protocol to force atomic reads and writes. Anything you agree on will work. There's probably a UUCP locking library floating around that you can use. In a previous life I found one for Linux. I've also implemented it from scratch. It's fairly trivial to do that too.
Check out the lockdev(3) library on Linux. It's for devices, but it may work for plain files too.
I like the socket idea best. There's no need to support HTTP or any RPC protocol. You can create a simple application specific protocol that returns requested information. If the server always returns the same info, then handling incoming requests is trivial, though the trivial approach may cause problems down the line if you ever want to expand on the possible queries. The main reason to use a pre-existing protocol is to leverage existing libraries and tools.
Speaking of leveraging, another option is to use SNMP and access the daemon as a managed component. If you need to query/manage the daemon remotely, this option has its advantages, but otherwise can turn out to be greater overkill than an HTTP server.