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 06:28:06 UTC