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.
Related
so i have been searching different ways to create client and server program (using visual studios in c++) and i came across RPC (Remote Procedure Call). But i noticed that this also uses a tcp/ip or udp connection.
so what the difference from using RPC to just a basic tcp/ip or udp connection to connect the client and server?
the code is completely different for example in RCP to use tcp:
reinterpret_cast<unsigned char*>("ncacn_ip_tcp"), // Use TCP/IP protocol.
reinterpret_cast<unsigned char*>("localhost"), // TCP/IP network address to use.
reinterpret_cast<unsigned char*>("4747"), // TCP/IP port to use.
but in other programs (eg using WinSock) it requires a lot more code
is one better than the other?
TCP/IP and UDP are protocols for data transfer (getting data packets from here to there). The former is connection-oriented and reliable, whereas UDP is connectionless and unreliable. Neither of them care what the data actually is (a file, a webpage, a video, etc).
TCP/IP creates a connection between two endpoints and then whatever data is sent at one end is received at the other.
UDP does not have a notion of connections, it's for a one-shot "send", without guarantees about delivery.
Several higher-level network protocols are built on top of TCP/IP and UDP. For instance, HTTP (that lets you view this webpage).
RPC is a higher-level protocol, which allows one computer to execute code on another computer. The lines of code you quoted are merely setting the configuration parameters for that RPC implementation.
Summary: RPC needs a network transfer protocol (like TCP/IP) to do its job, but RPC is a higher-level protocol and fulfills a different purpose than merely sending unstructured data from one computer to another.
You are talking about different notions. RPC is mechanism, TCP/UDP - way of communication.
RPC concept has a lot of implementations in different languages: read wiki. TCP/UDP - is transport.
So, in your case, "using TCP/UDP" means "creating your own RPC, based on TCP/UDP". I suggest you to read about existing RPC implementations and select most acceptable, based on your task.
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 have a certain application running on my computer. The same application can run on many computers on a LAN or different places in the world. I want to communicate between them. So I basically want a p2p system. But I will always know which computers(specific IP address) will be peers. I just want peers to have join and leave functionality. The single most important aim will be communication speed and time required. I assume simple UDP multicast (if anything like that exists) between peers will be fastest possible solution. I dont want to retransmit messages even if lost. Should I use an existing p2p library e.g. libjingle,etc. or just create some basic framework from scratch as my needs are pretty basic?
I think you're missing the point of UDP. It's not saving any time in a sense that a message gets faster to the destination, it's just you're posting the message and don't care if it arrives safely to the other side. On WAN - it will probably not arrive on the other side. UDP accross networks is problematic, as it can be thrown out by any router on the way which is tight on bandwidth - there's no guarantee of delivery for it.
I wouldn't suggest using UDP out of the topology under your control.
As to P2P vs directed sockets - the question is what it is that you need to move around. Do you need bi/multidirectional communication between all the peers, or you're talking to a single server from all the nodes?
You mentioned multicast - that would mean that you have some centralized source of data that transmits information and all the rest listen - in this case there's no benefit for P2P, and multicast, as a UDP protocol, may not work well accross multiple networks. But you can use TCP connections to each of the nodes, and "multicast" on your own, and not through IGMP. You can (and should) use threading and non-blocking sockets if you're concerned about sending blocking you, and of course you can use the QoS settings to "ask" routers to rush your sockets through.
You can use zeromq for support all network communication:
zeromq is a simple library encapsulate TCP and UDP for high level communication.
For P2P you can use the different mode of 0mq :
mode PGM/EPGM for discover member of P2P on your LAN (it use multicast)
mode REQ/REP for ask a question to one member
mode PULL/PUSH for duplicate one resource on the net
mode Publish/subscribe for transmission a file to all requester
Warning, zeromq is hard to install on windows...
And for HMI, use green-shoes ?
i think you should succeed using multicast,
unfortunately i do not know any library,
but still in case you have to do it from scratch
take a look at this:
http://www.tldp.org/HOWTO/Multicast-HOWTO.html
good luck :-)
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.
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.