> -----Original Message----- > From: users-boun...@open-mpi.org > [mailto:users-boun...@open-mpi.org] On Behalf Of > laurent.po...@fr.thalesgroup.com > Sent: Friday, April 21, 2006 4:54 AM > To: us...@open-mpi.org > 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 ports. 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 model. Does that help? Or do you still need TCP port restrictions? -- Jeff Squyres Server Virtualization Business Unit Cisco Systems
