<html>
<body>
If dropped messages are exported by MPI to the application, any recovery
mechanism by the application would have no need to place the lost message
back into the original sequence order. The application will know that the
message is dropped and none of the APIs in the transactional messages
proposal allow the application to put a message into some specific spot
in the message order. It is informed of the drop and it may do whatever
it wants. Importantly, if MPI notices that a message is corrupted and
tells the application that it is dropped, it will also be able to perform
correct matching with that gap in the sequence number. In fact, that
requirement must be included in the spec in order to make sure that we
don't have any ambiguities. If a message is dropped, it should be counted
as delivered when the application is informed of the drop.<br><br>
As for high-level recovery techniques, I can see a number of uses for
message drop information. It may be that the message is some sort of
periodic notification from the master to the slaves and dropped messages
are irrelevant. It may also be that the application is in fact using some
sort of protocol to overcome such failures. The point is that such
notifications can be useful and the main question for us is the
appropriate balance between clean semantics and the performance hit. The
fully transactional option is going to be expensive but very convenient.
However, we have a number of other options that will be quite useful for
use with higher-level recovery protocols and quite cheap. I think that we
should gravitate towards those but I thought it important to include a
variety of options for people to toss around.<br><br>
Greg Bronevetsky<br>
Post-Doctoral Researcher<br>
1028 Building 451<br>
Lawrence Livermore National Lab<br>
(925) 424-5756<br>
bronevetsky1@llnl.gov<br><br>
<blockquote type=cite class=cite cite=""><font face="Verdana">Actually,
it is most likely that MPI implementations that don’t try to deal
with<br>
dropped messages, can’t even detect that such event have
occurred. For<br>
such implementation I would expect them to be able to detect a
problem with<br>
failed communications only if the low-level library they use to
implement<br>
the communications, such as some OS bypass library, returns an
error when<br>
trying to post some sort of communications, or if the run-time used
by MPI<br>
detects a fail process, and propagates this information to the rest
of the<br>
processes in the application.<br><br>
The ONLY layer that can handle any sort of recovery from a live
communications failure -<br>
i.e. w/o some sort of check-point restart with or with out message
logging – is the<br>
MPI implementation itself. The application reposting a send
can’t take get around the<br>
lost data, because of the MPI message ordering requirements, unless
the implementation<br>
totally relies on another library to satisfy the MPI ordering
requirements (i.e. it does not<br>
generate some sort of message sequence number) and the message lost
is the last one<br>
that was sent. MPI is not allowed to attempt any matching if
there is a gap in the<br>
sequence number.<br>
</font></blockquote></body>
</html>