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

On Jan 30, 2006, at 2:46 PM, [email protected] wrote:
>
> There's a point of view that implementing one-way FAF over HTTP isn't
> worth the trouble, because you will have so much packet traffic at  
> a lower
> level, and either your application will have to wait for the (empty)
> response or more likely you will have to spin of some sort of  
> thread or
> other asynchronous construct to gather in the response and close the
> socket in parallel with the application proceeding.

The above assumes a very low level API, I think developers will  
normally use higher level abstractions that hide much of the detail  
and make ignoring the response as easy as dropping a return value or  
writing an empty call back method, e.g. in JAX-WS:

// using polling
Dispatch<SOAPMessage> stub = ...
SOAPMessage request = ...
stub.invokeAsync(request); // ignore the returned polling object

or

// using a callback
Dispatch<SOAPMessage> stub = ...
SOAPMessage request = ...
stub.invokeAsync(request, new AyncHandler<SOAPMessage> () {
         public void handleResponse(Response<SOAPMessage> res) {}
     });

I'm not denying that this is inefficient in network terms but from a  
programmer perspective its very simple.

Marc.


>   In other words,
> either (in pseudo code at the client):
>
>         fireAndForget(oneWayMessage) {
>                 s = openSocket();
>                 s.send(oneWayMessage);
>                 // too bad we're about to hang on the
>                 // next line, because we really wanted
>                 // to fire and forget
>                 s.receive(throwAwayResponse);
>                 s.close();
>         )
>
> -or-
>
>         fireAndForget(oneWayMessage) {
>                 s = openSocket();
>                 s.send(oneWayMessage);
>                 // too bad we're about to go
>                 // to the overhead and debugging complexity
>                 // of spinning off a thread
>                 // just to wait for the
>                 // response.
>                 fork {
>                         s.receive(throwAwayResponse);
>                         s.close();
>                         // 2nd thread terminates here.
>                 }
>                 // at least this branch will return
>                 // immediately to the application
>                 return;
>         )
>
> ...and yes, the above is pseudo code, not exactly legal in any  
> particular
> system I know of.  Note that in either case, quite a few TCP-level  
> packets
> are flying back and forth to set up and tear down these  
> connections.  If
> UDP meets your needs (e.g. datagram delivery semantics) it's a far  
> more
> appropriate transport for FAF.
>
> Having said all that, the short answer to your question is "yes".   
> If you
> choose to implement FAF on HTTP, and it may yet be useful to some  
> users, I
> think the implications are as you summarize them.
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.