W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2006

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

From: Yves Lafon <ylafon@w3.org>
Date: Fri, 13 Jan 2006 17:32:41 +0100 (MET)
To: Rich Salz <rsalz@datapower.com>
cc: "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>, "xml-dist-app@w3.org" <xml-dist-app@w3.org>
Message-ID: <Pine.GSO.4.64.0601131726400.1474@gnenaghyn.vaevn.se>

On Thu, 12 Jan 2006, Rich Salz wrote:

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

It does send all the bytes, a close will send the bytes that are in the 
buffer. In the case where you are sending something that fits in the 
socket buffer, close immediately the connection and have SO_LINGER 
disabled on the socket, then you are in the situation where you are really 
in the Fire-And-Forget (FAF) mode, as you won't be aware that the bytes 
reached the other end and you won't be notified of an error in transit.

So it is possible to do FAF with TCP, but it's only a corner case.

Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Friday, 13 January 2006 16:33:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:28 UTC