I have one "server" process running, which will fetch data over the network for other processes running on the same machine as the server process.
How should I transfer data from the local server process and the local clients?
For retrieval of network data by the server process, Boost.Asio as suggested by #radman is a good choice.
Between server and local clients, Boost.Interprocess would be more efficient as this is interprocess data transfer, not requiring network usage.
Each of these Boost libraries provides a ready-to-run wrapper around complex underlying Win32 APIs, so you will likely get a working solution faster by using the libraries than by building your own special-purpose code with equivalent function.
You should check out Boost.Asio it fits your problem and is solid.
Standard TCP sockets work fine for interprocess communications between multiple processes on the same machine or different machines. It's standard, supported on almost all platforms and in almost all programming languages. You should be able to find sample C++ code easily.
To connect to a socket on the same machine, use "localhost" as its name or 127.0.0.1 as its IP.
I believe Windows has named pipes, which would work similarly to the suggestions in the other answers (especially #Irish's TCP sockets suggestion). See CreateNamedPipe() for details.
Related
I'd like to use zerorpc as a internal service communication tool.
It seems zeromq can be perfectly used in multithread environments.
http://augustl.com/blog/2013/zeromq_instead_of_http/
However zerorpc documentation or tutorial is really sparse.
I'm trying to use zerorpc in a multithreaded environment (Django) and am stuck on to figure out how to reuse already connected socket (or pool of sockets) with zerorpc.
Is there an obvious solution?
There seems to be a communication breakdown here. ZeroMQ is great for multi-threaded environments, provided you follow the rules.
Rule # 1: ZMQ sockets are not thread-safe, you can't share them between threads.
That's the only rule. The usefulness of ZMQ in a multi-threaded environment is to have each thread spin up its own sockets which can connect to sockets in other threads and thus allow a more streamlined communication between threads.
So, you don't want to reuse already connected sockets. You want to create new sockets owned by your new threads.
I am developing 2 Windows services, one of them will send pictures and word files to other and other service will give a string answer. That services are in same computer.
I will develop same program's Linux version also.
Which way is the best for communication between services in Linux and Windows.
By the way I am developing that services with C++.
There're different options for your task:
Network. Establish TCP connection between your services, with service that asks as a client and service that answers as a server. It's possible to implement cross-platform solution using Boost.Asio or any other portable network library.
Shared memory. You can implement inter-process communication using shared memory. Cross-platform library: Boost.Interprocess.
Pipes. I don't know cross-platform library for this.
I would recommend to use TCP communication as more flexible solution.
I would suggest reading up on C++ sockets. You're probably going to want to use TCP sockets, since you want to ensure that the data being transferred does so correctly.
Try checking these links out:
Linux Sockets
Windows Sockets
You should search for IPC.
There are a lot of possibilities for inter process communication. Because you are not very specific about your problem and your requirements but I would suggest to take a look at boost::interprocess.
As long as you are sure that both services run on the same machine this will do it.
If you want to switch to a distributed approach you need something different.
Like XML-RPC, thrift or corba. Just to mention some possibilities.
I search for some C++ ipc lib that allow me to simple switch between named pipes (local use) and tcp ip sockets so i can send messages outside computer.
My app have to parts. First is users space app second is service. I need to send short messages between them.
Platform Windows
I would recommend
Using RPC for IPC
RPC enables applications to call
functions remotely. Therefore, RPC
makes IPC as easy as calling a
function. RPC operates between
processes on a single computer or on
different computers on a network.
http://msdn.microsoft.com/en-us/library/aa365574(v=vs.85).aspx
and Best RPC Programming Practices :
http://msdn.microsoft.com/en-us/library/aa373563(v=vs.85).aspx
What platform are you targeting? While not with named pipes, but memory-mapped files, our MsgConnect seems to fit your needs. It was designed specifically for tasks like yours. MsgConnect lets you send messages with data payload on the local system (using memory-mapped files or TCP or UDP sockets) or across network (using TCP or UDP sockets).
With RCF C++ you can switch your transport layer (be it named pipes, tcp and udp with Boost:ASIO, etc) quite seamlessly.
I would like to create a connection between two applications. Should I be using Client-Server or is there another way of efficiently communicating between one another? Is there any premade C++ networking client server libraries which are easy to use/reuse and implement?
Application #1 <---> (Client) <---> (Server) <---> Application #2
Thanks!
Client / server is a generic architecture pattern (much like factory, delegation, inheritance, bridge are design patterns). What you probably want is a library to eliminate the tedium of packing and unpacking your data in a format that can be sent over the wire. I strongly recommend you take a look at the protocol buffers library, which is used extensively at Google and released as open source. It will automatically encode / decode data, and it makes it possible for programs written in different languages to send and receive messages of the same type with all the dirty work done for you automatically. Protobuf only deals with encoding, not actually sending and receiving. For that, you can use primitive sockets (strongly recommend against that) or the Boost.Asio asynchronous I/O library.
I should add that you seem to be confused about the meaning of client and server, since in your diagram you have the application talking to a client which talks to a server which talks to another application. This is wrong. Your application is the client (or the server). Client / server is simply a role that your application takes on during the communication. An application is considered to be a client when it initiates a connection or a request, while an application is considered to be a server when it waits for and processes incoming requests. Client / server are simply terms to describe application behavior.
If you know the applications will be running on the same machine, you can use sockets, message queues, pipes, or shared memory. Which option you choose depends on a lot of factors.
There is a ton of example code for any of these strategies as well as libraries that will abstract away a lot of the details.
If they are running on different machines, you will want to communicate through sockets.
There's a tutorial here, with decent code samples.
Can pipes be used across LAN computers?
In particular I'm looking for Windows, but if you have more info on other platforms, that will also help others who find this thread later.
Yes they can.
Named pipes can be used to provide
communication between processes on the
same computer or between processes on
different computers across a network.
If the server service is running, all
named pipes are accessible remotely
http://msdn.microsoft.com/en-us/library/aa365590.aspx
It should also be noted that a TCP/IP connection is effectively a pipe in the sense that you shove bytes in one end and they come out the other. TCP/IP connections are available on pretty much any platform you are likely to care about.