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

Rich Salz wrote:

>> I'm also concerned about protocols like XMPP <message/>, which
>> provide a one-way transactional operation.  That is, IIUC, you can
>> tell whether your <message/> arrived or not even if you're not
>> expecting a response.
>
>
> I don't think so.  If the TCP layer detects a failure and reports it
> back up to the next layer, you have no way of knowing how many bytes
> of any pending messages were actually received at the other side.
>
> This is a limitation of any TCP-based protocol -- the layer using TCP
> needs to have an explicit ACK.  TCP is reliable as long as nothing
> goes wrong.

I think we're saying the same thing.  My criterion is that you either
know your message arrived safely or that /something/ bad happened.  That
would include "I don't know you got it but you actually did."  If you
know there's a failure you can then take extraordinary action.  The
practical difference is between "I can't rely on anything here so I need
to build acknowledgment/retries etc. on top of it before the application
layer can rely on anything (assuming it needs to)." and "This is
generally reliable so if anything actually does go wrong, it's probably
worth escalating."

This all assumes that the deployment is reliable enough that failures
are reasonably rare and are generally a signal that something noteworthy
is wrong.  This is a good assumption for *TP, but not a good assumption
for, say, UDP or certain messaging environments.  I'm asserting that
it's probably a good assumption for XMPP.  If my message doesn't get to
you, it's probably because of you're not there or I have the wrong JID
or something similar (which I probably need to know about) and not
because of some transient failure of the network (which, up to a point,
I don't need to know about).

>
>     /r$
>