[mpich-discuss] Suggestions solicited
Jayesh Krishna
jayesh at mcs.anl.gov
Thu Dec 4 11:34:13 CST 2008
Hi,
What you need is the server to do a MPI_Comm_accept() to accept
connection from volatile clients. MPI_Comm_accept() creates a new
communicator which can be used for communicating with the client. This
communicator can be disconnected without doing a MPI_Finalize().
A simple example (serial server) of this type of scenario is given below,
#################### server ###################
#include "mpi.h"
#include <stdio.h>
#define NUM_CLIENTS 10
int main(int argc, char *argv[]){
int i;
char portName[MPI_MAX_PORT_NAME];
MPI_Init(&argc, &argv);
MPI_Open_port(MPI_INFO_NULL, portName);
printf("portName = %s\n", portName);
for(i = 0; i < NUM_CLIENTS; i++){
MPI_Comm newcomm;
MPI_Comm_accept(portName, MPI_INFO_NULL, 0, MPI_COMM_WORLD,
&newcomm);
printf("Accepted a connection\n");
MPI_Comm_disconnect(&newcomm);
}
MPI_Close_port(portName);
MPI_Finalize();
}
#################### server ###################
#################### client ###################
#include "mpi.h"
#include <stdio.h>
#define NUM_CLIENTS 10
int main(int argc, char *argv[]){
char portName[MPI_MAX_PORT_NAME];
MPI_Comm newcomm;
MPI_Init(&argc, &argv);
printf("portname : ");
gets(portName);
MPI_Comm_connect(portName, MPI_INFO_NULL, 0, MPI_COMM_WORLD,
&newcomm);
printf("Connected to %s\n", portName);
MPI_Comm_disconnect(&newcomm);
MPI_Finalize();
}
#################### client ###################
You can do more sophisticated stuff by writing the port to a file etc
(Unfortunately publishing and lookingup names won't work with smpd for
now).
As long as you use SMPD as the process manager (default on windows &
configure with "--with-pm=smpd" on unix) & make sure that all the machines
have the same data model (eg: same architecture) you should be fine.
Regards,
Jayesh
-----Original Message-----
From: mpich-discuss-bounces at mcs.anl.gov
[mailto:mpich-discuss-bounces at mcs.anl.gov] On Behalf Of Hiatt, Dave M
Sent: Thursday, December 04, 2008 10:52 AM
To: mpich-discuss at mcs.anl.gov
Subject: [mpich-discuss] Suggestions solicited
My topology is as follows; I have my MPI cluster on pile of Linux
workstations, I have network access from an AIX server and from a bunch of
Windows workstations. Right now to trigger a run, I have to Rlogin to the
node 0 Linux box and run mpiexec to start.
My plan is to convert the parallel application into a "service" hanging
blocking recv message with the material calculation details for the next
set of calculations.
The idea would be to let the cluster receive requests from any of the
Windows work stations.
My first idea, was to have a workstation become part of the cluster in a
special communicator, that is start a process, MPI::INIT, send a message
to node 0 with the calculation data, and Finalize, and cease execution.
Then later return repeat the steps and retrieve results. But it was
pointed out to me that the only official method that can operate after
MPI::Finalize is run is MPI::Finalized, I wondered if the following is
possible.
If the process on the workstation that I propose to be volatile runs, and
terminates and a new process comes back to request the results, is that
within the bounds of the standard and a supported approach?
Also, as long as the hardware the Linux and Windows workstations are
running on are the same "Endian", would this still be considered a
homogenous MPI cluster, or is there any issue between Windows and Linux?
How in general do others approach this, that being, allowing workstations
send in new requests for runs and later come back and retrieve the
results.
If you lived here you'd be home by now
Dave Hiatt
Manager, Market Risk Systems Integration CitiMortgage, Inc.
1000 Technology Dr.
Third Floor East, M.S. 55
O'Fallon, MO 63368-2240
Phone: 636-261-1408
Mobile: 314-452-9165
FAX: 636-261-1312
Email: Dave.M.Hiatt at citigroup.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20081204/c7190f82/attachment.htm>
More information about the mpich-discuss
mailing list