Style / Theory question regarding client-server apps

Hello all,
First some background about my project. I'm writing a client server app for load testing another application on a Solaris box. The client is in VB6 and the server is in C. (these are the only tools available to me at the moment.) The server wil receive a request from the client which will consist of which "type" of load test to run (number of connections, which test scripts, and a number of other parameters.) The server will launch the test and provide status back to the client (load, number of current connections, failures, etc.)

BTW, currently this is all done with Perl and Korn shell scripts on the Solaris box. Status is tracked by tailing a number of log files.

Finally, my question. There seems to be a number of different strategies to writing a server (duh) and I don't know which is best for my project. I thought about having the server be nothing more than a listener which forks off a process for each connection which comunicate with the client. Then I thought maybe only the server should communicate back to the client and the server would use fork off the "test" processes and use shared memory to relay status information.
Crude Diagram:
client <--TCP--> server <--shared mem--> forked test processes

Now I'm reading through my copy of Steven's UNIX Nework Programming and I see an example of a server that handles everything within a single process. I am thoroughly confused about which approach to take with this.

I'm not sure if I was clear enough in describing my applications goals but is there anything anyone can see that would make you pick one strategy over another?

>is there anything anyone can see that would make you pick one strategy over another?
Among apparently equal options, go with the one which has the simplest implementation.

-Prelude

Well, it sounds to me like you don't even need to fork off child processes, I mean it doesn't sound like there will be multiple connections ? if this is right, you don't even need to fork, this is done to handle multiple connections.

The server which does it all in "one connection" as you said, is probably using select ? you wouldn't even need this, as you would only have the one client fd to test for read, anbd then perform whatever function you need to do based on that.

However, if I misunderstood, and there is going to be multiple connections, I think going with:
select(2) - http://bobo.fuw.edu.pl/cgibin/man2ht...n2/select.2.gz

As you see Stevens did some testing(it's in the book), select is faster, and doesn't use up as much resources as forking off children.

Quote:

---

Among apparently equal options, go with the one which has the simplest implementation

---

That was the point of my question actually, are they equal options? My guess is there are advantages to each I'm not aware of. Select() using fewer resources than fork() for example.

Quote:

---

I mean it doesn't sound like there will be multiple connections ?

---

Probably not. I can't say what would happen in the future but this test is not really designed to be run by multiple people so there would not be multiple clients out there. Unless I wanted the ability for other people to monitor a test in progress or something. I'll hold that feature for version 2.0. :)

Thanks guys, it looks like I'll try a single process, no forking, and I'll add select if I need multiple connections.