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
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
On Mon, 2004-11-15 at 16:36, Sean Hefty wrote:
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
Hal So do we just keep the cancel around for some time period to
Hal make sure this doesn't occur ? If so, should cancel also have
Hal its own timeout or should some arbitrary timeout be used to
Hal handle this case ?
I don't think we should worry about this. If a consumer sends
Hal Rosenstock wrote:
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
On Wed, 2004-11-10 at 13:43, Sean Hefty wrote:
Hal Rosenstock wrote:
Currently if no matching send request is found, the received MAD is
freed (around line 1035 of the current mad.c).
In this case, timeout too short, etc., is this the correct behavior ?
Or should the receive packet
