My thinking was that the peer to peer model would have both sides call connect only. The peer to peer connection model only kicks in when both sides are in the REQ sent state.Is this observation based on the wording used by the spec? if yes, can you point on the sentence/s that does it?
I was basing this on the active side state diagram.
From my reading, I could not conclude that implementing it in a way that both sides do listen and later set the peer to peer bit on the REQ such that --if-- there's a "matching" REQ for the incoming REQ one side sends REP and the other side ignores the incoming REQ etc - is against the spec.
This leaves a window where a REQ can be received the call to listen, and the call to connect.
I understand that under TCP there's also a notion of peer to peer and client/server connections, I'll give it a look next week to see what's the foundations over there.
That would be good. I think the difference is that with TCP the listener and connector would be distinguished by their local ports, so its clear how to direct an incoming request. IB doesn't assign a SID to a connector. I'm not sure how TCP handles the race condition.
- Sean _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
