Ralph Castain 414f4e9783 Try to provide a real hostname for the remote host to aid in debugging ... Refs trac:4908 This commit was SVN r32748. The following Trac tickets were found above: Ticket 4908 --> https://svn.open-mpi.org/trac/ompi/ticket/4908		2014-09-17 00:39:49 +00:00
..
configure.m4	Remove the old configure option for disabling full rte support - we now use the OMPI rte framework for such purposes	2013-02-28 01:35:55 +00:00
help-oob-tcp.txt	Can't use show_help as the RML has already been enabled, but we haven't successfully connected back to the HNP. So use opal_output instead and hardwire the message.	2014-09-16 22:21:02 +00:00
Makefile.am	Use the correct abstraction layer name for the data dirs	2014-05-08 14:32:24 +00:00
oob_tcp_common.c	Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.	2014-06-06 02:24:17 +00:00
oob_tcp_common.h	Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.	2014-06-06 02:24:17 +00:00
oob_tcp_component.c	Properly protect the MCA parameters being registered by the OOB/TCP component when IPv6 is enabled	2014-09-02 14:53:00 +00:00
oob_tcp_component.h	Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.	2014-06-06 02:24:17 +00:00
oob_tcp_connection.c	Try to provide a real hostname for the remote host to aid in debugging	2014-09-17 00:39:49 +00:00
oob_tcp_connection.h	Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.	2014-06-06 02:24:17 +00:00
oob_tcp_hdr.h	Don't use "size_t" for the nbytes field in the header - use uint32_t to ensure that ntohl/htonl correctly match it	2013-12-23 21:39:49 +00:00
oob_tcp_listener.c	Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.	2014-06-06 02:24:17 +00:00
oob_tcp_listener.h	As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:	2013-08-22 16:37:40 +00:00
oob_tcp_peer.h	Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.	2014-06-06 02:24:17 +00:00
oob_tcp_ping.h	Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.	2014-06-06 02:24:17 +00:00
oob_tcp_sendrecv.c	Try to resolve the simultaneous connection problem by being a little more careful about the choice of returned status when a connection is refused. As before, have the higher vpid of the two peers retry the connection, while the lower one waits. This can happen in a couple of places, so try to hit them all. Since this is hard to test, will ask Gilles to give it a try since he's the one who is seeing it.	2014-09-16 18:59:36 +00:00
oob_tcp_sendrecv.h	Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.	2014-06-06 02:24:17 +00:00
oob_tcp.c	Remove an unnecessary optimization that can cause more trouble than it's worth - just try all the addresses that are given to us.	2014-08-20 20:58:07 +00:00
oob_tcp.h	Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.	2014-06-06 02:24:17 +00:00