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

Rich Salz writes:

> > A subtle problem occurs if you try to implement true FAF on a req/resp
> > protocol like HTTP.  Repeating the sender code from above:
> >
> >         s = socket.new(destinationURI);
> >         s.send(Message);
> >         // note that client does not wait here
> >         s.close();
> >
> > Depending on the local implementation, I don't think the 
> above obligates
> > the messaging system to even send the message.
> 
> I think it does.  It depends on semantics of the API, but I am not
> aware of any "socket" library that allows a close() to bypass the
> normal TCP close mechanism, which requires that all bytes in-transit
> have been received.  Not providing this guarantee (proper TCP
> connection shutdown) would mean that every TCP-application would
> have to build its own exit protocol on top of the TCP streams.

Thanks, I think you're right in the specific case of TCP and HTTP.  I 
actually realized it this morning and then saw your note.  In some sense, 
this traces to the fact that the TCP streams are reliable and happen to 
each have a sort of Fire-N-Forget semantic, not just at the API level, but 
also at the packet level.  The packets that close the connection are, I 
believe, ordered with respect to those that send the final data.  Even if 
they are delivered in the wrong order, I expect that the data is in 
general reliably transmitted, unless the network partitions or retries 
fail.

Having acknowledged that, I should note that the above pseudo-code was not 
intended to be HTTP/TCP specific, but rather a model for the API that you 
typically use with Req/Resp.  As you say, what actually happens depends on 
the semantics of the API (and, I think, the protocol it's driving).  I 
believe that a Req/Resp MEP is best designed to work with a broad range of 
underlying protocols, and I think it's easy to imagine the design of a 
lightweight req/resp transport that responds to a close by immediately 
suspending further attempts to deliver.

Bottom line:  I acknowledge that I was wrong about TCP, but I continue to 
suggest that it would be imprudent to make the entire response optional in 
you req/resp MEP.  I remain OK with our current plan to make the response 
envelope optional.  Do I have the facts right now?  I think so.  Thanks.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------