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