Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > The CM should track remote QPs that are either: > > 1. Part of an active connection, or > 2. A connection that has been placed into timewait.
Agree here. > The CM should detect attempts to connect such remote QPs, and reject them. That's stretching what the spec says though. It says reject in case 1. > The > entire paragraph is referring to stale connection handling, Not really, stale connection handling is the one below. This paragraph talks about release in general. > and I believe the > reference to timewait is included as part of that general discussion. So CM currently tracks the remote QPN that QP in timewait *as* connected to. What you get then is, e.g.: - local side sends dreq - remote side sends drep, places qp in timewait - local side gets drep places qp in timewait - remote side gets out of timewait reuses qp and sends req - local side sees remote QP was used as peer for local qp that now is in timewait, and rejects the connection And here we are, connection request that was part of a perfectly valid connection setup sequence gets rejected as supposedly stale. In your interpretation, I see no way *not* to get rejects which breaks applications such as SDP which are careful to perform DREQ/DREP sequence gracefully, but report rejects directly to the user. -- MST _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general