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
Related
Is it possible to migrate a single and particular TCP connection inside a running process in one machine to another machine using CRIU tools in Linux?
What I want is to dump a particular TCP Connection information in a memory and transfer this information to a peer machine. Inside this machine, I will use the dumped information to recreate the the migrated TCP connection. Does anyone have an example or tutorial in c language?
I am aware about different solutions like SockMi which provides Kernel Module + User Space APIs to migrate a certain TCP Socket. However, I want to use CRIU tools since it is part of Linux Mainline.
Right now we only have the TCP migration functionality integrated into CRIU tool. It sits in the sk-tcp.c file, the whole TCP-repair code is there, though it's bound to the rest of CRIU.
On the other hand, we've been asked for TCP-only migration for quite a while, it's possible to pull this code into smth like libcriutcp.so, but it will require patching. You're welcome to participate to the https://github.com/xemul/criu/issues/72
I have an application that began its life as a C#-based Windows GUI that used marshalling to talk to a C DLL.
I now need to separate the Windows client and DLL so that the client is installed on a remote PC and communicates with the C DLL over the internet.
A further complication is that I want to have multiple Windows clients connecting to the C DLL.
This whole world is new to me, so excuse me if the following are naive questions.
My questions:
0) What is the best method for having the client communicate with the DLL over the internet? TCP/IP Sockets?
1) I need to make modifications to my DLL to have it service multiple clients. But I need some piece of middleware that collects the queries from the different clients, feeds them to the DLL, and then sends the results back to the appropriate client. Is there any code (such as node.js) that would facilitate this?
Regarding: What is the best method for having the client communicate with the DLL over the internet?
Your suggestion of using TCP/IP could certainly (and likely will) be part of the solution, but there will be other components of the solution as well. The direction you choose will in part be made by answering whether you are using standard marshaling (COM), or custom? At the very least, your problem description suggests a scenario requiring interprocess communications.
There are many ways to implement. This diagram maps out a general approach, that based on your description might apply:
Components of Interprocess Communications
Read more here
Regarding: make modifications to my DLL to have it service multiple clients...
The dll is simply a file like any other. Several processes can read, and subsequently own content from, a file as long as the processes doing the reading adhere to common file access rules. I do not think you will have to modify your dll, at least for that reason. Just make sure the processes accessing the dll comply with safe file access protocols. (Safe file access).
I have an application and library that interacts with low-level hardware protocols. Now I'm writing an erlang application for fast parsing of data and send it to distributed databases. However, I'm a newbie at erlang and I've stuck at simple thing: what is the efficient way to connect C library(or application) with erlang and how to notify erlang that another block of data is ready for processing (e.g. how to call erlang function from C library or trigger an event)? Time is important here, and what shall I use -- simple ports, driver ports or NIFs? Or there are better ways for solving my task?
as an option, you can run your C application as hidden erlang node using erl_interface lib. http://www.erlang.org/doc/apps/erl_interface/ei_users_guide.html#id56593 . And send messages to real erlang node http://www.erlang.org/doc/apps/erl_interface/ei_users_guide.html#id60866, or use rpc - remote proc calls to perform http://www.erlang.org/doc/apps/erl_interface/ei_users_guide.html#id57714
You should try simple port first sending events to stdout. If the bandwidth of such implementation is enough, you have the benefit of erlang vm be safe from crashes of your application. If you need more then using port driver is an option, that interface was developed exactly for such purposes.
I am currently building a chat server (meebo style).
The architecture is something like this.
Bitlbee over libpurple is on host B. Its a trivial server on data center.
User communicates with bitlbee via web server (just like meebo) on Host A. The backend of this web server maintains chat session. It just translates the user commands to proper bitlbee comamnd and sends back to host A.
The most important part here is that host A will be deployed in embedded Linux.
I have 2 questions.
To keep the chat session persistent I am thinking of using node.js. As its much more easier to create a real time application with persistent connection. But I doubt if its supported in such platform.
If I use C instead of node.js (I am not using any web server) I can talk to the irc server at host A by libirc. But how do I implement all the web server features in C (like session, url/cookie/post data parsing etc) ?
Also if you think my approach is wrong or there is a better approach please tell me how can I improve this architecture?
Note: This is NOT a high volume chat server.
If building V8/Node.js is prohibitive on the embedded platform, the next best thing would be to take the event loop and platform layer (libuv) and HTTP parser (http-parser) of Node, both written in C and use those as a starting point. These are the same libraries used to build Node.js so they are battle tested and will give you the performance characteristics you seek.
Ryan Dahl, author of Node.js, demonstrates exactly how to use libuv and http-parser to build an asynchronous web server in C.
Put a ZNC server between Bitlbee and the web-based IRC client. Bitlbee will think that the user has never logged out and ZNC can maintain a backlog of messages until the user connects again with the web client.
I would try to go with node.js if that is your choice, also what embedded system is it? As knowing that would help more. Also, another plus for node.js is that it does have session handling built it, but if you wanted to do it in C try and see if you can get a sqlite wrapper running on the embedded device to store the session information.
But, if possible stick to something with less work on embedded devices, feels bad to reinvent a lot of stuff or have to fiddle with compile issues for your device.
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.