W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

RE: Completing the tables SRR MEP description.

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 15 Apr 2002 10:17:52 -0400
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
Cc: "Williams, Stuart" <skw@hplb.hpl.hp.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Message-ID: <OF27B934E3.6EBB54DB-ON85256B9C.004CF81B@lotus.com>
Thanks.  I'm also curious about your reaction to my specific suggestion. I 
am nervous about requiring even the simplest clients to handle the 
overlap.  That seems like a big mistake.  So:  why not make the default 
"no overlap".  If you want streaming, then as a client, you must signal 
that with a header.  The header triggers a feature with the semantic that 
the request originator MUST pull responses while sending the request, and 
the responder MAY stream the response?  I think that's very SOAP-like, 
it's the best of both worlds, and the only downside is the need for the 
client to include the header.  Later, we could always name a separate 
binding that mandates streaming in all cases.

I strongly feel that the default binding should not put such a tricky 
burden on the clients.  Even though HTTP in prinicple always allows it, in 
practice it's rare to have a large POST overlapped with a large response. 
I bet that many stacks are buggy in this area or don't even try.  Deadlock 
is a very ugly failure mode.  I think we should keep the base case simple, 
especially since we have an easy way to the extension.  I'm neutral as to 
whether we should publish the streaming feature on day 1 and as normative. 
 Many thanks.

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







"Williams, Stuart" <skw@hplb.hpl.hp.com>
04/15/2002 06:26 AM

 
        To:     "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>, "Williams, 
Stuart" <skw@hplb.hpl.hp.com>
        cc:     "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
        Subject:        RE: Completing the tables SRR MEP description.


Hi Noah,

You make two points...

Firstly overlapping request/response opens the possibility of a deadlock,
and explain at least one instance of how that arises. I believe your
analysis is correct and the implication is that *if* we allow the
overlapping case, then ALL requesting nodes MUST be capable of supporting 
it
in order to avoid the deadlock condition. Support of overlapping
request/response at responsing nodes would be OPTIONAL. In the
non-overlapping case, the responsing node needs to be able to fully 
receive
the request message (possibly processing on the fly) before releasing the
response message. If the responding node has insufficient resources to
handle the request message it can then reflect the failure via the
undlerlying protocol (say via status codes [explicit] or dropping 
underlying
connection (implicit)).

So, I think overlapping request/response is a place we could go, but I 
think
it would place a mandatory burden on the the requesting node.

The second point you make is the addition of significant complexity to the
state-machines that describe the MEP. Certainly it makes them less 
trivial.
I have roughed out the table for the requesting node, which introduces two
new states. One to cover concurrent sending and receiving (Req+Rec) and 
one
to cover the circumstance where the response completes before the request.
The "message tx/rx failures" are really failures of the underlying 
protocol
however signalled.

I think the modified responding FSM would follow a very similar pattern - 
so
I've only done the one here. Each would then result in an additional two
states to be specified in a binding spec - one could minimise the size of
these descriptions where there are common actions and inputs but pulling
them out and describing each one only once - in the case of similar or
parameterisable actions.

Heres a summary of my thoughts:

 - Leaving the possibility of dead-lock open would be a bad thing.

 - Overlapping request/response is a place we could go, at some mandatory
cost to a requesting node.

 - The increased complexity in the description is bearable (IMO).

I think the crutial question is whether we are prepared to place a burden 
on
all requesting nodes to be willing to support overlapping responses.

Not supporting overlapping responses also places a conformance requirement
on responding nodes, that they MUST NOT start sending a response before 
they
have recieved the end of the correspodning request.

Regards

Stuart
--

Modified Requesting Node MEP State Transition Table.
----------------------------------------------------

Present          Input                           Next  Action
State                                                            State
============================================
Requesting               message tx              Fail
(Req)                            failure
                                 -------------------------------
                                 message tx              Wait
                                 complete 
                                 -------------------------------
                                 start           Req+Rec
                                 message rx 
===========================================
Request+                 message                 Fail 
Receiving                tx/rx
(Req+Rec)                failure
                                 -------------------------------
                                 Local                           Fail
                                 Abort
                                 -------------------------------
                                 message tx              Rec
                                 complete
                                 -------------------------------
                                 message rx              FinReq
                                 complete
===========================================
Finish           message tx              Fail            (Response message
Requesting               failure                                 already 
received
(FinReq) may be 'good').
                                 -------------------------------
                                 Local                           Fail 
                                 Abort
                                 -------------------------------
                                 message tx              Success
                                 complete
===========================================
Waiting          message rx              Fail
(Wait)           failure
                                 -------------------------------
                                 Local                           Fail
                                 Abort
                                 -------------------------------
                                 start                           Rec
                                 message rx
===========================================
Receiving                message rx              Fail
(Rec)                            failure
                                 -------------------------------
                                 Local                           Fail
                                 Abort
                                 -------------------------------
                                 message rx              Success
                                 complete
===========================================


> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 14 April 2002 13:02
> To: Williams, Stuart
> Cc: 'xml-dist-app@w3.org'
> Subject: Re: Completing the tables SRR MEP description.
> 
> 
> In case it's not obvious, among the reasons that deadlock is possible 
with

> overlap of response with request:
> 
> Consider a streaming service.   Perhaps it takes in a long stream of 
> characters, uppercases them, and sends them back.  The server is coded 
to 
> start sending the response before the request is fully received.  This 
is 
> allowed, but not mandated by HTTP (as an example of an underlying 
> protocol).  The problem is that success depends on the client being 
coded 
> to deal with the overlap as well.  If you have client built in a more 
> obvious way, I.e. to not start looking for the response before the 
request

> is complete, then deadlock can result:  the response is streaming back, 
> and the client won't read any of it.  Gradually the response stream 
backs 
> up, and the server is unable to write to it.  Maybe or maybe not the 
> server buffers more response for awhile, but sooner or later it has to 
> stop reading the request.  Now the request stream backs up and we have 
> deadlock.
> 
> Even if deadlock is not a problem (client and server are both smart 
about 
> streaming), getting the state machine tables just right is tricky with 
so 
> much asynchrony.
> 
> So, this is a case of a valuable capability, that is not absolutely 
> mandatory on day 1 (my opinion).  It will probably be of great value to 
a 
> small number of clients and servers, and a source of many bugs and 
> testability problems to the others.   It will be very hard to spec well. 
I

> have no clearly compelling suggestion, but my current leaning would be: 
> have the base binding not stream.  I think (not sure) we could always 
add 
> a feature to enable overlap, possibly signaled by a header sent from the 

> client (which would ensure the client's commitment to avoid deadlock). 
It

> would also allow us to write the complex version of the spec later, I 
> think.  Does this work?
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
Received on Monday, 15 April 2002 10:36:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT