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

Jean-Jacques Moreau writes:

> May I dare a summary? So a FAF MEP would not really be FAF at the HTTP 
> (and lower) level, but it would nonetheless provide a useful abstraction 

> (and fit well to other transports). The MEP user will not (have to) care 

> and the MEP implementor will simply have to obey the HTTP semantics and 
> discard the HTTP response.

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

Received on Monday, 30 January 2006 19:47:13 UTC