This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
The code that discovers local interfaces specifically ignores any
interfaces that are not up or are just local loopbacks. My guess is
that the person who wrote that code long, long ago was assuming that
the sole purpose was to talk to remote nodes, not to loop back onto
I imagine it could be changed to include loopback, but I would first
need to work with other developers to ensure there are no unexpected
consequences in doing so.
On Jan 5, 2009, at 3:49 PM, Terry Frankcombe wrote:
> But why doesn't tcp work on loopback?
> On Mon, 2009-01-05 at 07:25 -0700, Ralph Castain wrote:
>> It is currently a known limitation - shared memory currently only
>> works between procs from the same job. There is an enhancement coming
>> that will remove this restriction, but it won't be out for some time.
>> On Jan 5, 2009, at 1:06 AM, Thomas Ropars wrote:
>>> I've tried to use ompi-server to connect 2 processes belonging to
>>> different jobs but running on the same computer. It works when the
>>> computer has a network interface up. But if the only active network
>>> interface is the local loop, it doesn't work.
>>> According to what I understood reading the code, it is because no
>>> component can be used in this case. "tcp" is not used because
>>> it is the "sm" component that is used for processes on the same
>>> But in that case it doesn't work because "sm" is supposed to work
>>> for processes of the same job.
>>> I know that this use-case is not very frequent :)
>>> But Is there a solution to make it work ? or is it a known
>>> limitation ?
>>> users mailing list
>> users mailing list
> users mailing list