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

> 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.

(The fact that HTTP doesn't have a QUIT or CLOSE method seems
like a strong argument in favor of my view.)

Even if this were so, TCP supports the concept of a half-close,
where one side indicates to the other side, and gets a positive
ack from that side, that it is not sending any more data.  In
many socket libraries, the API is called shutdown().

Are MEPs point to point or end to end?
        /r$


-- 
SOA Appliance Group
IBM Application Integration Middleware
* This address is going away; please use rsalz@us.ibm.com *

Received on Thursday, 12 January 2006 06:16:46 UTC