Follow-ups to today's call: 2 (timing and the trickiness thereof)

I agree with Noah that a major difference (I think Noah would say /the/
major difference) between the flavors of request-response and true fire
and forget is to do with timing.  You can generally do either over the
other (actually you can't: see /below/), but you may get nasty surprises
when, say, the callback that's waiting for a response to your FAF
request hangs around longer than you want.

Unfortunately, trying to define things like "longer than you want" or
"long-running operation" is tricky.  To some people microseconds may be
a long time.  Others may not mind waiting for minutes or hours.

The way out, I believe, is just to talk about what steps you have to go
through in each situation.  In request-response, receiving a response --
and thus waiting for it -- is part of the contract (modulo failure).  In
FAF, it isn't.  Or more accurately, in cases where you still do have to
wait for something, it's pushed into a different operation.  It's not
part of the contract for the FAF MEP.

I'm afraid this is either tautological or completely obscure (or both).

/Below/: Multicast pub/sub protocols are inherently FAF.  If I try to
layer request-response on top of such a protocol using WSA, I will get
any number of responses (including zero) depending on who's listening to
the multicast.