> -----Original Message-----
> From: users-bounces_at_[hidden]
> [mailto:users-bounces_at_[hidden]] On Behalf Of
> Sent: Friday, April 21, 2006 4:54 AM
> To: users_at_[hidden]
> Subject: Re: [OMPI users] users Digest, Vol 261, Issue 4
> > That being said, we are not opposed to putting port number
> controls in
> > Open MPI. Especially if it really is a problem for
> someone, not just a
> > hypothetical problem ;-). But such controls should not be added to
> > support firewalled operations, because -- at a minimum --
> unless you do
> > a bunch of other firewall configuration, it will not be enough.
> This point is a real problem for me (but I may be the only
> one in the world...).
> I have to build a system that uses MPI softwares and non MPI COTS.
> I can't change TCP ports used by the COTS.
> Restricting MPI TCP/UDP port range loks like being the best
> solution for me.
Ok. Can you describe what you're doing / what you need? If the fear is
that you'll conflict with other user-level applications that are using
fixed port numbers, you may have this problem with other applications
that use dynamic TCP ports as well.
Some scenarios may already be handled, too. For example, if you have
your user-level, fixed port applications being launched and are
guaranteed to be running before the MPI processes are running, then
there's no problem (because OMPI -- just like any application that uses
dynamic TCP ports -- will only use ports that are not already in use).
Or, if your applications are using restricted ports (e.g., below 1024),
then OMPI will not conflict because we do not currently use restricted
Specifically, I think you only need to restrict OMPI's ports if you want
to launch your non-MPI apps that use fixed, non-restricted ports either
at the "same" time or after MPI apps are launched, then I can see how
this would be necessary (although the chances of a collision are pretty
small, they are nonzero).
Indeed, with a quick peek in /etc/services, I see a fair number of
services that have port numbers >1024 (subversion, postgres, finger,
...etc.). It strikes me that many (all?) of these fit the "will be
launched at boot up time, so even though they're not in the restricted
range, they'll be the first ones to ask for that port and therefore
there's no problem" category. My point here: there's precedent for this
Does that help? Or do you still need TCP port restrictions?
Server Virtualization Business Unit