> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Viswanath Krishnamurthy
> Sent: Friday, June 30, 2006 1:26 PM

> In the current communication manager (CM) implementation how is the REP MAD
> getting lost handled. When the REP gets lost, the cm_dup_req_handler gets called
> which currently enters the default condition and does nothing.  The client retries
> the number of timers it is configured to and fails.  If the first REP gets lost, the connection
> never gets established. So what should be the behavior ?

The IBTA standard in section 12.9.7 defines this situation in the state machine.

 

In this case the Active side will have sent a REQ.  It will be in REQ Sent state (or REP Wait in passive side sent an MRA).  In these states the Active side will have a timer running.  If the REP is lost, the Active side will timeout and move to the “Timeout” state.  In this state, the active side has the option of resending the REQ or sending a REJ and giving up on the connection attempt. In general it is best for the active side to perform a few retries before it gives up.

 

During this sequence the passive side will think it has sent its REP (eg. the one which was lost) so it will be in the REP Sent state (see 12.9.7.2).  In this state if it receives another matching REQ, it is to resend its REP.  There is also a timer on the passive side in this state (waiting for the RTU).  If the passive side times out it will move to RTU Timeout and has the option to resent its REP or send a REJ and give up the connection attempt.  Here too it is best for the passive side to perform a few retries before giving up.

 

Todd Rimmer

 

_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to