We help IT Professionals succeed at work.

Child process (fork) sending message to other child processes

jchristn123 asked
Hello experts,

I am writing a program that uses sockets and forking.  What I'm having it do is receive a message on one of the child processes, and then that message should be distributed to the other child processes.  You can think of it like a chat server as that is the most similar concept.  

I'm at a point where I'm wondering "how should I implement" - specifically the piece where data comes into the read buffer for a child process, and how it is then transmitted from each of the child processes to their connected peers.

My pseudo code is this...

  setup socket parameters
  socket call
  bind call
  loop {
    accept call (blocking)
      child process
          listen for messages
          when i get a message, send to other child processes
      parent process
          close file descriptor

There's the RIGHT way to do it (which seems like a lot of work, and I want to PROTOTYPE this first) which is to build a dispatch-type of service, which learns about FDs and other metainformation from the child processes when spawned.  This dispatch could act as a registrar, and add/remove child processes as they are born/die.

The dispatch could also become a messaging relay, i.e. a child process could say "send my peers this message", since it has this metadata.

As per the above, writing a dispatch is the right way but will take a painfully long time.  Anyone know of a simple way to do this using C?

Watch Question

Top Expert 2009
I gather you're thinking of something similar to the IRC protocol ? If so, you'll find lots of interesting information starting from here :


and more specifically, the RFC :


Now, keeping the IRC protocol in the back of our heads, the server (parent process if you want) would be the central component : it accepts new connections (new clients), and every client sends and receives messages from the server. Clients (childs) never communicate with each other directly - they send their message to the server (parent), which broadcasts it to all clients (childs).

>> Anyone know of a simple way to do this using C?

It's not very complicated. We already have all the information we need : the server knows all its children, and each child knows the parent. They can now use IPC (inter-process communication) to communicate. Several ways are possible, but the easiest is probably using pipes. Have one (bidirectional) pipe between each child and the parent (so there will be as many pipes as there are children).

Here's some example code :


Just a question : do you really want to fork off a process for every client ? That's potentially a lot of processes !! You could opt for threads instead (and use a shared message buffer for communication), or even a more monolithic design with just one server thread that does everything (it just keeps the socket descriptot for each client, and whenever a message arrives on one of the sockets, it is forwarded to all others).
evilrixSenior Software Engineer (Avast)

Picking up on what I8 has said, you seem to be making an awful amount of hard work for yourself here. I think it would be useful if you could actually state the objective of this exercise. Like I8, I am wondering why you need to be forking new processes. Unless you need each instance of a connection to be discrete so that it may, for example, out live it's parent process there is little point in doing this; you really are making life hard. Light weight threads would make you life so much simpler. Have you looked at pthreads or the Boost threads C++ library, which provides a x-platform abstract C++ interface for powerful threading concepts? With all the connections in the same process managing communication between them becomes so much simpler as they are all sharing the same process and therefore address space.

Both threads and processes are methods of parallelizing an application. However, processes are independent execution units that contain their own state information, use their own address spaces, and only interact with each other via interprocess communication mechanisms (generally managed by the operating system). Applications are typically divided into processes during the design phase, and a master process explicitly spawns sub-processes when it makes sense to logically separate significant application functionality. Processes, in other words, are an architectural construct. By contrast, a thread is a coding construct that doesn't affect the architecture of an application. A single process might contains multiple threads; all threads within a process share the same state and same memory space, and can communicate with each other directly, because they share the same variables.



I got around the whole thing by using a couple of simple global variables.  Thanks for everyone's input!

BTW - I switched to a multi-threaded model as opposed to a forked model - you both were right, there wasn't enough to justify using fork.
evilrixSenior Software Engineer (Avast)

>> I got around the whole thing by using a couple of simple global variables
I suggest you Google "siq_atomic_t",  "Race Condition" and "c++ keyword volatile" (all without the quotes).
evilrixSenior Software Engineer (Avast)

You might also want to look at Boost threads


Hi evilrix - remember I said I was "prototyping" - very well aware of race conditions and issues/risks associated with using global variables.  Do appreciate the link on boost threads, will definitely check it out.  Thanks
evilrixSenior Software Engineer (Avast)

>> remember I said I was "prototyping"
Even prototypes should work :)

>> very well aware of race conditions and issues/risks associated
What about the other suggested searches (the reason I suggested them)?

Good luck.


Prototype works great.  Sounds like you have something against global variables, which I think work very well when controlled properly :)  Don't worry, the prototype is monolithic.
evilrixSenior Software Engineer (Avast)

>> Prototype works great.
Debug build? If so, try it in release build!


Explore More ContentExplore courses, solutions, and other research materials related to this topic.