CODEWITHSUNDEEP
c++socketstcpipc
user3253591
user3253591

Reputation: 13

multi way inter process communication

There are 10 processes in my machine and each should have the capability to communicate with each other. Now the scenario is all the 10 processes should be in the listening state so that any process can communicate with it at any time. Again when required it should be able to pass a message to any of the processes. I am trying to code it with C++ and unix tcp/udp sockets. However I don't understand how to structure it. Shall I use UDP or TCP, which would be better? How can a process listen and send data simultaneously.

I need help.

Upvotes: 1

Views: 410

Answers (4)

beardedN5rd
beardedN5rd

Reputation: 185

what you want to do seems to be message passing.

before trying to build it yourself, take a look at boost mpi

Upvotes: 0

stefaanv
stefaanv

Reputation: 14392

This question applies to any language, so the answer is not C++ related.

When given a choice, look for a library to have an easier communication (e.g. apache-thrift).

About TCP/UDP: TCP is typically slower but more reliable, so by default, go for TCP, but there might be reasons for choosing UDP, like streaming, multicast/broadcast,... Reliability might not be an issue when all processes are on the same board, but you might want to communicate with external processes later on.

A threaded process can use the same socket for sending and receiving without locks.

Also, you need some kind of scheme to find out to what port to send to reach a process and with TCP, you need to decide whether to use static connections or connect every time you want to send.

Upvotes: 0

Tony Richards
Tony Richards

Reputation: 401

The decision of UDP vs TCP depends on your messages, whether or not they need to be reliably delivered, etc.

For pure TCP, each peer would have a TCP socket on which each process accepts connections from other peers (and each accept would result in a new socket). This new socket is bi directional and can be used for sending / recieving from one peer to another. With this solution, you would need some sort of discovery mechanism.

For UDP, it's much the same except you don't need the accept socket. You still need some form of discovery mechanism.

The discovery mechanism could either be another peer with a well known (via configuration, etc) address, or possibly you could use UDP broadcast for the discovery mechanism.

In terms of zeroMQ, which is a slightly higher level than raw sockets, you would have a single ROUTER socket on which you're listening and recieving data, and one DEALER socket per peer on which you're sending data.

No matter the solution, you would likely need a thread for handling the network connections using poll() or something like that, and as messages are received you need another thread (or thread pool) for handling the messages.

Upvotes: 1

Rahul_cs12
Rahul_cs12

Reputation: 984

you can run each process as severer & span 9 more thread to connect other processes as client.

Upvotes: 0

Related Questions