I'm trying to make two-way many-to-one communication between programs in Linux.
My plan is the following: One program called "driver" that talks with the hardware needs to communicate with an unknown number of applications in Linux.
I read that one of the most common ways for inter process communication is "named pipes".
The question I haven't found yet is: How new programs should notify the driver that a new program is running so that one more connection (named pipe) between the new program and the driver enstablished?
All programs will be written in C++
In essence, what you've described is a server/client relationship between programs; what each program does on either side of the communications bridge is probably irrelevant.
Even though these processes appear from the question to be intended to be on the same machine, networking is still available to you via localhost.
If you're not wedded to pipes, why not use a port for the driver (server) known to each program (client), to which the server listens?
That's pretty much the underlying philosophy of X-Windows, I believe.
Plus, there should be lots of reliable code out there to get you started.
I also think sockets may be a better solution, but if you really want named pipes, I'd do it this way:
The server opens a pipe named channel_request for reading. Any new client opens it for writing and writes a unique ID. (PID should work). The server reads this id and creates a named pipe called channel_[id]. The client then opens channel_[id] for reading and can start receiving data.
Note that linux pipes are unidirectional, so if you want two-way communications as shown in your diagram, you will need to open both a channel_[id]_out and a channel_[id]_in.
Related
I have written a c++ app on Windows that uses a secondary thread to communicate with a PLC. The content of the messages are vectors (of fixed size around 120) of uint_16t. The interface also allows to send something to the PLC.
I am really new to this so I want to start correctly. I would like now to separate the communication from the app and run it in a separate process. One reason for that is that I would like to write other apps that could also use this process for communicating with the PLC. The communicating process would thus organise and distribute the messages, since all app don't share the same messages from or to the PLC. So I still need to receive the vector of uint_16t (and for that I need to let know to the communicating process which one to read!) but also to send some things to the PLC. Thus I would need a bidirectional communication.
I have seen that there are many possibilities to achieve this but I would like to communicate via Message Queues (Message Passing). If possible, I would also like to allow apps on other computers to connect to this communicating process.
I am therefore looking for a c++ library to do that. I would appreciate any advises about which one to favor.
I can use message queue from Boost but it doesn't allow to communicate with another computer.
As a secondary question related to this one, I would like to start the communicating process if at least one interface process is opened. How to achieve that synchronization?
I thank you in advance for your help.
I would like to create a linux app which appears as a serial port (eg /dev/ttyTEST). This app will listen for commands sent to the port, and respond back.
Is this possible using Qt/C++ ? I haven't done kernel programming so I'm hoping this is possible in user space.
Everything depends on what the application using such device expects.
If /dev/ttyTEST is to behave like a real serial device and respond properly to all ioctl's that set its speed etc., then this can't be done from userspace. It wouldn't be too hard to implement in the kernel space, though.
If /dev/ttyTEST only needs to be a tty, then provide a pseudo tty.
If /dev/ttyTEST is merely to be something another application can write to and read from then socketpair() does it.
If you have control over the application's code, then you can have it check whether the device is a socket pair or a real character device, and ignore the failures of the serial-port-specific APIs on a socket.
I’m new to IPC and I’m trying to implement a secure IPC method (not related to encryption).
I’m developing a system in C++ using Visual Studio 2010 (but will be ported to others platforms Linux/MacOS/FreeBSD), this system have a process “A” that needs receive and send a XML to other process “B” on the same computer, but will exist around of 14 process like “B” (B1, B2, ..., B14) that need send/receive a XML to the process “A”.
The process “A” will acts as a proxy/bridge between every process “B”, all data/XML that the process “B” must send, will be sent to the process “A”, and just the process “A” will sends data/XML to the process “B”.
I’m looking for an IPC method to exchange this data between the process “A” and “B1…B14”. The shared memory sounds good to do this, but any process can write/read to the address, so this isn’t secure (I know that is possible to set permission access).
I’m trying to find an IPC method that:
Must be a local only method, I need avoid remote connections.
For security reasons, when a process opens a “channel for communication” to send/receive the data, other process can’t use the same “channel” (unlike shared memory or Boost Message Queue that is possible to write on this channel, or NamedPipe that is possible open other instance with the give name), I want to avoid fake/malicious process. TCP sounds good for this, because isn’t possible that two process listen on the same port (but isn't local only).
3- The process “A” will be a service, and some processes “B” will run as service too and others processes “B” will run as a unprivileged user, so this must not be an administrator-only feature.
4- This project will be code-closed, so I can’t use a code/lib based on the GPL license.
5- If possible, cross-platform (Windows/Linux/MacOS/FreeBSD).
Can someone suggest a suitable IPC technique, either built into the OS or requiring a third-party library?
Short answer:
Windows Pipes for Win32.
Anonymous local sockets for Linux(and family).
Long answer:
On Windows platform there are following commonly used alternatives:
Memory mapped files
Named Pipes
Network sockets (mostly IP)
The unfortunate fact is that none of the above is local-only by nature. Files are shared by storage access, pipes are available due to common RPC/LPC routing and IP is a subject to routing/forwarding configuration (even when using loopback).
I personally recommend using pipes on Win32. They are acting more or less like local sockets on Linux (with some differences though).
On Linux platform:
Shared memory
Pipes
Local sockets (including anonymous ones).
Pipes and local sockets are secure, and in different scenarios each of them have own benefits. As you have multiple client/single server scenario, I would favor local (AF_LOCAL) socket programming. You can either use named sockets (with file-based access control), or anonymous ones. Both options are pretty secure (unless attacker gains local access).
Links
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365780(v=vs.85).aspx
http://manpages.ubuntu.com/manpages/lucid/man7/unix.7.html
I have a controller which has a serial port and ethernet. I want to retrieve an event and the data associated with this event from the event directory through the serial or ethernet port of the controller. I do have a packet format (request packet data) for the specified event to be retrieved. Can anyone tell me how to retrieve the data by sending a request through the serial port? I am beginner and not that much well-versed in programming.
You will need to have some kind of a program running on your embedded platform, listening to the serial port and answering requests. This kind of program is usually called a "daemon" (pronounced the same as "demon"; just like "Caesar" rhymes with "sea star").
If you already have a daemon, you will need to figure out what format it uses. Since I have no idea what you might have I cannot even guess.
If you will be writing your own daemon, you will need to choose some sort of protocol. Personally I like the JSON format for a serial protocol; it is simple enough that you can extract data just using sscanf() from the C library if there is not a better library available, and of course it's easy to build JSON strings just using sprintf().
http://json.org/
What you want is the Serial Programming Guide for POSIX Operating Systems. If you are bound to Windows for some reason, you get POSIX through installing Cygwin. Expect to become familiar with man pages like termios and fcntl since you'll first have to set the serial port parameters to work with your device, though they're likely to be the standard 8-N-1 at some rate. Then it's a matter of reading and writing bytes to the port's file descriptor. You're more likely to be using the low level open(), close(), read(), and write(), which are a level below the stdio (printf, fopen, stdout) you're more likely to be used to as a newer programmer.
Computers these days often lack the RS232 serial port, so if you need one you can find a cheap USB adapter. Be aware that USB adapters don't necessarily implement some of the ancillary signals (RTS,CTS,etc.) in my experience.
Also look into libraries for your specific needs and situation.
You should specify the controller for more useful answers.
Your controller should support any data exchange protocol. You can find this info in documenttion. May be, it supports MODBUS or MODBUS TCP. In this case you can use any modbus compatible software.
I am working with legacy C++/MFC/Win32 code. The project multiplexes various serial protocols over separate physical serial ports, one per client system, to a common front end data repository.
Since the program was originally designed to communicate over serial ports there are many assumptions in the code as far as setup and management of serial events go: ACK/NAK transport verification, inner-byte delay checks, etc…
The existing architecture leverages overlapped reads and writes with event notification via WaitCommEvent.
I have been tasked to add another client interface, using a single client pipe server; which, like the serial ports, will support one client per “file”.
In reading the docs for WaitCommEvent it looks like it was designed to work with OS abstracted physical communications devices; like serial ports.
The simple question, can I leverage the existing serial skewed “wait” model to work with a pipe, or should I go ahead and virtualize it so that it can be overridden it with specific pipe logic?
Thanks to those (the minority for sure) of developers who know what I am asking.
I can't find a good reference right now, but it is my understanding that WaitCommEvent only works with communications resources and that a pipe is not defined to be a communications resource in the same sense as e.g. a serial port. WaitCommEvent waits for the underlying driver to set certain bit-flags, like when new characters arrive, and I don't believe pipes (or files) work that way internally.