asked on

Child process (fork) sending message to other child processes

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)
fork
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?

Thanks!

ASKER CERTIFIED SOLUTION

Infinity08

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

evilrix

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.

-Rx.

jchristn123

ASKER

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.

evilrix

>> 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).

evilrix

You might also want to look at Boost threads
http://www.boost.org/doc/html/thread.html

jchristn123

ASKER

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

evilrix

>> 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.

jchristn123

ASKER

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.

evilrix

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

http://www.devx.com/tips/Tip/15424
http://www.devx.com/tips/Tip/13750