On Tue, 16 Sep 2003, David Geldreich wrote:
> I would like to be able to using LAM/MPI executable on two networks
> separated by a firewall.
>
> What should I do to limit the ports used during lamboot and the one
> used during execution. I suppose that the network communications depends
> on which RPI I choose (lamd vs tcp) ?
Unfortunately, such a low number of people have asked for this feature
that we have never implemented it. LAM will use random TCP and UDP ports
its communication.
There are three main places where LAM will use random port numbers:
1. During lamboot. There are multiple places where TCP sockets are opened
between the lamboot process and the newly-booted programs on each target
node.
2. During steady-state lamd operation. Each lamd opens a UDP endpoint for
communication with all of its lamd peers.
3. For MPI communications in the tcp RPI module. The tcp module uses
random TCP port numbers to communicate with each of its other MPI process
peers.
It probably wouldn't be *too* hard to make these use fixed port numbers
(or stay within some defined range). Most of these situations should use
the centralized sfh_* functions in (share/etc/socket.c) to open the
listening ports. Although these sfh_* functions do accept an argument
that allows the invoking function to request a specific port number, I
believe that we currently pass in a port number of -1 everywhere (meaning:
any port). So it may not be difficult to simply change the invoking
sections to request a specific port number (or loop over a range of
acceptable ports until one can be used).
I think the most annoying aspect of this is not really requesting specific
ports as it is providing a way for the user to specify what ports they
want used... although the relatively new introduction of -ssi parameters
on the lamboot and mpirun command line may actually now make this feasible
and not overly annoying to the user. For example:
lamboot -ssi boot_base_port_range 5000-5010 ...
mpirun -ssi rpi_tcp_port 5011 ...
These are off the top of my head, and would require a little more
refinement, but the general idea seems workable.
However, I can pretty much guarantee that we won't be able to get to this
in the near future -- our plate is pretty full with other projects in
LAM/MPI. :-(
Patches would be greatly appreciated, though! This is open-source
development, after all. :-) If you want to move this conversation over
to the lam-devel list, I'd be happy to point you at the right code, answer
questions about how to implement this, etc.
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
