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

Let me briefly repeat what I said on today's telcon for the benefit of 
those who weren't on it:

* I've learned a lot from this thread.  As you can tell from my first 
note, I thought I had all the details right and I've picked up many 
nuances from the discussion.  So, I think this has been useful.

* In particular, I am now convinced that in the particular case of TCP/IP, 
the risks of sending and then immediately closing a connection are very 
low;  in most reasonable circumstances a good effort will be made to 
deliver the message.

Having said that, I have not changed my position that there are risks in 
doing this with some protocols, and that even if send/close would always 
deliver with high probability, I believe the reasons for separating the 
One-Way MEP from Request/Response remain strong.

* On the first point, see for example the Microsoft description of WinSock 
at [1] which discusses the risks of using early close with Asynchronous 
Transfer Mode networks:

"Notes for ATM

The following are important issues associated with connection teardown 
when using Asynchronous Transfer Mode (ATM) and Windows Sockets 2:

* Using the closesocket or shutdown functions with SD_SEND or SD_BOTH 
results in a RELEASE signal being sent out on the control channel. Due to 
ATM's use of separate signal and data channels, it is possible that a 
RELEASE signal could reach the remote end before the last of the data 
reaches its destination, resulting in a loss of that data. One possible 
solutions is programming a sufficient delay between the last data sent and 
the closesocket or shutdown function calls for an ATM socket."

The purpose of SOAP MEPs is not just to exploit TCP/IP, but to map well to 
a range of networking infrastructure.  I'm not an ATM expert, but I have 
seen high performance networks that use the application response message 
as the packet-level confirmation that a message has been sent.  This is in 
the realm of problem-oriented protocols, in which the transport- and 
application-levels are designed and optimized together.  So, I still 
believe that there exist networks in which Firing and Forgetting is a 
mistake if the underlying network believes a reply is coming.

* The second point is probably more important:  even if it were always 
safe to use all request/response protocols as if they were one way, I.e. 
by closing after sending at the "requester" and declining to send anything 
in place of a response, I still believe that the one-way MEP should be 
documented separately from Request/Response.  Reason:  MEPs aren't just 
there to justify SOAP implementation on some transport, they are a means 
by which applications can say "here's what I'm expecting out of my SOAP 
network".  Let's say you have a UDP network and an application that wants 
one-way fire and forget SOAP datagrams.  With separate MEPs, there's no 
problem.  The UDP binding implements "one way" (but probably NOT 
req/resp), the application says "I need one way", everything works.   If 
there's just one MEP, then the UDP binding has to support it. Ooops.  Now 
we need to build req/resp on UDP.  You can do it if you're willing to keep 
some state and timeouts, but it's a mess, and it's certainly not in the 
spirit of pure UDP.  The alternative is to say "well, this UDP binding 
supports the uber-MEP, but only in a limited mode, which we'll 
call....ahh.....the one way mode of the req/resp MEP.  Now the application 
wants to say:  I want a network that supports what I need, how do I say 
that?  Answer:  well, all networks support the same MEP, so that doesn't 
help you much, but you might say you want one that does a good job of 
running it in the one-way mode.  That doesn't seem very compelling to me. 
Having separate MEPs makes it easier to document your support for 
particular messaging idioms on particular networks.  While one-way on HTTP 
may work moderately well (I think it's still something of a misuse of the 
spirit of the protocol), I don't think that having to support req/resp on 
UDP is a good thing at all.  So, separate MEPs please.

Thanks!

Noah

[1] 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/closesocket_2.asp
[2] 
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/atm.htm#wp1020558

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








Yves Lafon <ylafon@w3.org>
Sent by: xml-dist-app-request@w3.org
01/13/2006 11:32 AM
 
        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>
        Subject:        Re: The deep difference between request/response 
and fire-and-forget



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 Wednesday, 18 January 2006 22:02:04 UTC