Hal Rosenstock wrote:
After Roland's query this AM, I am looking at this some more:
On Wed, 2004-11-10 at 13:43, Sean Hefty wrote:
The second case where I can see this happening is if the client canceled the send, and I'm not sure that we'd want to give the client an unmatched response in this case.
So do we just keep the cancel around for some time period to make sure
this doesn't occur ? If so, should cancel also have its own timeout or
should some arbitrary timeout be used to handle this case ?
My personal take would be to avoid adding that complexity. E.g. a client sends a MAD with TID 5, cancels 5, sends 5, cancels 5, sends 5. A response is now received. What should the MAD layer do?
I don't see issues with silently dropping any MAD that we're not ready to receive. For unsolicited MADs, I don't see a reasonable alternative.
For solicited (response) MADs, I have a hard time seeing why a client would ever want an unmatched MAD, unless they're trying to duplicate MAD layer functionality higher in the stack. For user-mode, this may make sense, but I'm not convinced that duplicating the request-response functionality in user-mode is the best option (versus moving all of RMPP to user-mode).
For the sourceforge stack, we handled this by defining "raw" MAD services that did nothing other than send/receive MADs. Clients using a raw service were responsible for performing RMPP, request/response matching, and handling timeouts. This worked, but the MAD layer still needed to route received MADs to the correct client.
- 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
