In addition to communicating via a file (both CGI and client2 are on the same machine is what I understood, also that client2 is running as a daemon waiting for data), you can also have them communicating via a socket, its port must be blocked by firewall so that client2 is not accessed externally.

Every time client1 calls the CGI script, a new instance of the script is created. Which means that a new socket to client2 must be created every time. So, this solution too has its overheads.

Assuming you do not have too many requests, then writing data to a file may not be a bad solution. It could be faster if you created a ramdisk and write/read all your data files there.

If there are multiple parallel requests from client1 to server then you will have a problem with unique datafiles/requests to client2 and also keeping track of whose request was first so that it is served first. Both problems easily sorted but with added overheads.

The most controversial solution would be for the server to system() client2 with all of its data either as a commandline param or as a file.

If you are flexible and client2 is not already a standalone program, why not write client2 as a Perl module and have your CGI script do something like:

# in CGI script
use Client2;
my $client2 = new Client2($params);
my $output = $client2->process($data);
print $output;
[download]

That's the route I would take.

bw, bliako