[mpich-discuss] mysterious network access

[Darius Buntinas]

Dave's right.  We create a socket for the possibility of spawns or connect/accepts.  I recall that we tried something where we didn't create the socket or poll on it until we got an MPI_Open_port and that it wasn't trivial.  The fact that we're still unconditionally creating the socket tells me that we didn't get it right and probably gave up.

I was getting similar firewall messages from mpiexec as well until I did something to my firewall (probably clicked  "block all incoming connections").

-d

On May 27, 2012, at 5:53 PM, Dave Goodell wrote:

> On May 28, 2012, at 5:55 AM GMT+09:00, Geoffrey Ely wrote:
> 
>> But, I do not see why share-memory code should be requesting a network connection. Has anyone else seen this problem? Are there MPICH diagnostics I can turn on to see what is going on under-the-hood?
> 
> My guess is that it's angry about the socket that we create for incoming connections.  We always create it, because there could be dynamic process connections later on and it simplifies the code this way.  It's setup here:
> 
> http://trac.mcs.anl.gov/projects/mpich2/browser/mpich2/trunk/src/mpid/ch3/channels/nemesis/nemesis/netmod/tcp/tcp_init.c#L55
> 
> Probably we should consider making that a conditional socket based on an environment variable.  We also could defer this socket's creation until the user makes a call to MPI_Comm_spawn or MPI_Open_port (assuming the socket isn't already needed for regular TCP connections to other processes in MPI_COMM_WORLD).  Either of these changes is nontrivial though, since I think that there is an assumption about the existence of the listener socket baked into much of the TCP state machine code.
> 
> -Dave
> 
> _______________________________________________
> mpich-discuss mailing list     mpich-discuss at mcs.anl.gov
> To manage subscription options or unsubscribe:
> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss