Re: The deep difference between request/response and fire-and-forget

Noah,

On 1/11/06, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> wrote:
> Crucially, after sending the request, the client is waiting.  For any
> reasonable underlying request/response protocol, even the decision by the
> responding application that no explict response message is forthcoming
> (e.g. the s.close by the responder above) will trigger some sort of
> signaling to the client.

In the case where the protocol supports optional responses, that won't
be the case.  It also won't be the case if the protocol supports
pipelining, doesn't support out-of-order responses, and one of the
responses blocks indefinitely (ala HTTP).  Or if the client terminates
the connection prior to any would-be response.  Maybe other scenarios
that I'm not thinking of too...

> I noticed this in DaveO's draft [1] where he failed to explicitly include
> in the HTTP binding an indication of what was to happen at the point that
> the server decided that it was in fact not sending back a message of any
> sort.  Is it to close the connection?  I'm not sure that's good HTTP
> practice, but it does work.

If no response is coming back, then the connection is unusable, and it
would seem to me to be a best practice for the server to close the
connection so as to free up resources which are being unnecessarily
consumed.

>  Note, however, that this would NOT be the
> same as fire and forget.  In the req/resp model, the client MUST wait
> until the connection closes or the response comes back.

I don't believe that to be the case, even for mandatory responses. 
Just because a protocol supports responses, even if a server using
that protocol sends one, it doesn't obligate the client to acknowledge
its existence in any way, since clients can simply choose to timeout. 
They can also set that timeout arbitrarily low if they desire.

> From this I conclude that we cannot do what DaveO originally suggested,
> I.e. we cannot make the response in our existing MEP truly optional.

I think you can as long as you outline the implications of doing so,
both generically and specificically (to the protocol).  For an example
of the latter, with HTTP you'd have to describe the implications for
connection management; that you have the choice of pipelining HTTP
messages down a connection using pipelining, but once you're done you
can't reuse the connection.  As an example of the former, you'd have
to acknowledge that the resulting state of the system is
indeterminate.

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

Received on Thursday, 12 January 2006 19:24:09 UTC