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.