On Mon, 2004-11-15 at 17:37, Sean Hefty wrote:
> It's just that before supporting this, I'd like
> to make sure that routing unmatched responses is really the right solution.
>
> I.e. Is this something that kernel mode clients would need?
I think you mean user mode clients.
> Does it
> make
Hal Rosenstock wrote:
If we want to route the MAD to the corresponding agent, however, we can
do that. But doing this only seems useful if a client is duplicating
functionality, which only makes sense to me for user-mode clients.
If we want to limit this to user mode clients only, we would need
On Mon, 2004-11-15 at 17:15, Sean Hefty wrote:
> If we want to route the MAD to the corresponding agent, however, we can
> do that. But doing this only seems useful if a client is duplicating
> functionality, which only makes sense to me for user-mode clients.
If we want to limit this to user m
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 rec
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 sen
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'
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 j
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 ca
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 recei
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 be given to a matching MAD agent with a
receive handler (perhap
Hi,
I was just rerunning all of my test cases and have a question about the
MAD layer receive processing:
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 sh
11 matches
Mail list logo
