Basically this is a similar model of running that software uses often. One very close to it would be Apache for example.

When you fork off a child, it inherits all the parents handles, so what happens with the Apache example is
1) Main daemon listens on port 80
2) request comes in
3) Parent forks child to deal with request
3a) Child inherits all open filehandles and variables
4) Parent goes back to listening for requests
4a) Child processes request
5a) Child returns results
6a) Child wait x time prior to telling the Parent it is done with said request

While this isn't exactly technically accurate as to how Apache itself does it (as it maintains a pool of children to do its work, and only spawns more if its overloaded), its close enough for comparison.

Questions:
1) Is it worth it to queue the data up, or should you be processing real time streams?
2) How many "clients" are we talking about?
3) How far apart "logically" as well as "physically" are the "clients" and "servers"?
4) What is an acceptable timeout for client->server, server->client, server->server communication?

Yes it is possible to talk to a running process, provided the process has opened a 'socket' to deal with I/O. A socket can be a connection to a file, connection to the network stack, connection to a fifo or named pipe (which are really files, but we will ignore that for a sec and treat them differently), etc..

Named pipes are kinda cool. Alot of X applications make use of fifos in the /tmp or /var/tmp directory. Basically there is this handle they check, if there is data in the handle they slurp it in and process it, if not they go back to what they were doing and check back again later.

Personally I think your design is fine, and there are plenty of examples of forking servers, which is a fine search string to Super Search or Google for.

Hope that helps, and happy hacking

/* And the Creator, against his better judgement, wrote man.c */