how would I implement communication between Linux programs written in C? Specifically, I want the following:
My program can run in multiple instances. Upon startup, I want that my program detects all other instances of my program that are already running and then it should be able to send a text string to them. On the other hand, I also want that the instances that are already running get notified that a new instance has been started and they should also be able to send a text string to the new instance.
Could someone point me to some APIs which could be used to implement such a software design on Linux? On Windows, I can simply enumerate over all windows, check their class names to find out all instances of my program, and then register a custom message with the system that I can use to send data to them. But how would I do this on Linux?
Thanks for any hints!
You have a lot of options:
Named pipes;
Msg commands (msgget, msgsend);
Using TCP sockets;
Using UNIX domain sockets;
Using a third party broker, like DBus or ActiveMQ;
If it is for a standalone machine, and only one stream of data, I would recommend the option number 1.
1st pointer: The Linux Kernel: IPC Mechanisms
2nd pointer: Detailed documentation on using shared memory
I would probably start with named pipes
I have used sockets and multicast for that very purpose. This allows distribution of processes among several computers on the same LAN.
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 would like to inject a shared library into a process (I'm using ptrace() to do that part) and then be able to get output from the shared library back into the debugger I'm writing using some form of IPC. My instinct is to use a pipe, but the only real requirements are:
I don't want to store anything on the filesystem to facilitate the communication as it will only last as long as the debugger is running.
I want a portable Unix solution (so Unix-standard syscalls would be ideal).
The problem I'm running into is that as far as I can see, if I call pipe() in the debugger, there is no way to pass the "sending" end of the pipe to the target process, and vice versa with the receiving end. I could set up shared memory, but I think that would require creating a file somewhere so I could reference the memory segment from both processes. How do other debuggers capture output when they attach to a process after it has already begun running?
I assume that you are in need of a debugging system for your business logic code (I mean application). From my experience, this kind of problem is tackled with below explained system design. (My experience is in C++, I think the same must hold good for the C based system also.)
Have a logger system (a separate process). This will contain - logger manager and the logging code - which will take the responsibility of dumping the log into hard disk.
Each application instance (process running in Unix) will communicate to this process with sockets. So you can have your own messaging protocol and communicate with the logger system with socket based communication.
Later, for each of this application - have a switch which can switch off/on the log.So that you can have a tool - to send signal to this process to switch on/off the message logging.
At a high level, this is the most generic way to develop a logging system. In case you need any information - Do comment it. I will try to answer.
Using better search terms showed me this question is a dup of these guys:
Can I share a file descriptor to another process on linux or are they local to the process?
Can I open a socket and pass it to another process in Linux
How to use sendmsg() to send a file-descriptor via sockets between 2 processes?
The top answers were what I was looking for. You can use a Unix-domain socket to hand a file descriptor off to a different process. This could work either from debugger to library or vice versa, but is probably easier to do from debugger to library because the debugger can write the socket's address into the target process while it injects the library.
However, once I pass the socket's address into the target process, I might as well just use the socket itself instead of using a pipe in addition.
I have just managed to write my first windows driver (havent registered it yet- but i managed to get the things created!).
I wondered if someone can give me a high overview of how I could achieve the following:
I would like to write a driver which will implement some behaviour when a network packet is received by the computer, before windows does what it does with the packet, i'd like to take this data and output it to the console of a C or C++ program.
Lets assume I have a C/C++ program written, which has a console. How does the C/C++ program interact with the driver I wrote which is hooking the network activity? Is it simply some C code which calls my drivers, the function returns the data as an object and then I can use that object to display in the console?
Thank you in advance for any possible replies
You don't need a driver for this task. Use packet sniffer library like PCap (actually you'll need WinPCap). It's really simple to capture packets and print them to console.
Alternative way is raw socket. But desktop Windows (as opposite to Windows Server) limits raw socket functionality.
If you really want a driver, or have a requirement to manipulate or filter packets before they hit the windows network stack you need to look into filter drivers.
This filter driver can then expose a device file on which your user space application can then read/write. The windows DDK contains examples.
I am trying to create two applications. One application should take inputs from user like name, address, phone number and send that information to the other application to store it. This should also be capable of reading the stored address information from the other application.
My assumptions for this:
I am planning to use system() process in application1 to create application2.
For communication between these processes, shared memory as IPC.
Can anyone suggest me whether this is the correct way for this task or is there any best and easy approach for this task.
Thank you.
You could take a look at google protocol buffers if you are looking for communication between processes in python , java or c++.
It is clean and elegant and works across files and sockets.
You can communicate using sockets between the two processes.
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.