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.
Related
so I want to send an int32 (or any 4 bytes data) from one pc to another, the size of the data will always be the same, I don't need any checking to see if both pcs are online or any disconnect function, if pc2 didn't receive the data or he went offline, I just want pc1 to send the data, if pc2 is offline nothing happens and if it's online it store it somewhere.
Most tutorials I've found uses a server way of connecting, so there are 3 pcs, 2 clients and 1 server, client1 sends data to the server and the server sends it to client2, but is there a way to send it directly to client2, as if client2 is the server?
There are two common protocols used to send raw data over an ip based network. They are called TCP and UDP and serve slightly different approaches.
TCP is connection oriented and relies heavily on the server client model. On host acts as a server and accepts incoming requests on a predefined socekt. After the TCP connection is setup, you have a duplex (two-way) stream that you can use to exchange data.
UDP is a packet oriented protocol. One host (usually called the server) listens to imcoming packets and can answer them. No real "connection" is established tough.
You probably want to use UDP. Note that altough this protocol does not establish a connecion, there still needs to be at least one host, that is waiting for incoming data on a predefined port. This one is usually called the "server". However also the client can bind its UDP socket to a specific port and thus can act as a "client" and a "server" during the same time.
You can setup both hosts to listen and send on/to the same preefined port number and achieve a connectionless packetoriented way to exchange data. That way both hosts act as server and client simultaneously.
How you actually implement this, depends on your operating system. On Linux (and other POSIX compatible OSes) you can use standard UDP sockets, on Windows there is some equivalent API. Either way I suggest you to first follow a tutorial on how to program a standard TCP server and client, as most of the operations on the sockets are similar (create the socket, bind it to an address:port, and read/write data from it).
I am interested in programming a replacement for the TCP protocol at the transport layer of network communications. I still wish to use a standard/unaltered IP stack but want to layer my own replacement for TCP over it.
I am very familiar with network programming at the application layer.
What I would like to do is "install" my replacement on two windows machines that any call program designed to use TCP would use my replacement instead.
I would then test this by making a simple program between the two machines to connect a socket, send a message, and disconnect. There should be no difference to the application side on if they are using standard TCP or my implementation.
I do understand that a computer installed with my implementation would not be able to communicate with a system that doesn't have it installed as my system would use my implementation and the other would use the "standard" protocol.
I understand I am not going to revolutionize network connectivity or better what many super smart people have done. This is for personal education/edutainment purposes.
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 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.