On Wed, 2006-03-22 at 15:51 -0800, Sean Hefty wrote: > >The user, being the IWCM, will always see a CONNECT_REPLY to a connect > >downcall. > > I understand that a CONNECT_REPLY event is generated in response to calling > connect(). But can any events (e.g. CLOSE) follow that without the user > taking > any other action?
Yes. I think there are two possibilities involving close: CLOSE (abortive shutdown) and DISCONNECT followed by CLOSE (graceful shutdown). Either of these could happen if the remote peer issued iw_cm_disconnect after iw_cm_accept'ing the connection and before the local user did anything. BTW, if the CONNECT_REPLY was delivered with a status of RESET or REJECT, no other events should be received on this cm_id because it would never have transitioned to the ESTABLISHED state. The previous paragraph applies when CONNECT_REPLY was delivered with a status of ACCEPT (0). > > >> How are > >> additional events that are generated in this case handled, or is that even > >> possible? I.e. you've notified the user of a new connection request, when > >the > >> connection is aborted. The user hasn't called accept() or reject() yet. > >> > > > >The provider must handle this and _not_ pass any events up until the > >IWCM has accepted or rejected the connection request. In the case of an > >connect request upcall, followed by a connection abortion, followed by a > >accept_cr downcall, the accept_cr downcall would return an error like > >-ECONNRESET. OR the provider could allow the accept_cr to succeed, > >which moves everything to RTS/CONNECTED, then generate a CLOSE upcall. > >Either way is correct methinks. I think providers would do the former. > > Okay - this sounds like this case is handled. > > So, I'm trying to determine when a CLOSE event will be generated, and I > _think_ > it's in these two cases: > > 1. After calling connect(), and a successful CONNECT_REPLY event. > 2. After calling accept(). > The CLOSE event must delivered exactly once after the connection has gone to established (but more precisely, the QP --> RTS). > Then trying to determine if there are any races here with the user destroying > the cm_id at any time. There may be. But I'd like some consensus that these races represent bugs and not architectural flaws. That is, the approach is ok, but my code stinks. Then we can move forward incrementally fixing bugs instead of ripping up the carpet and starting over on concrete. > > - Sean > _______________________________________________ > openib-general mailing list > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
