Re: [wsrm] Detailed proposal to allow Batching of Acks and RM faults using ResponseReply pattern.

[Tom Rutt <tom@coastin.com>]

Sunil Kunisetty wrote:

>Tom Rutt wrote:
>
>  
>
>>Lines 1019 thru 1024 currently state the following:
>>
>>“
>>- *Response *: An Acknowledgment message (or Fault message) MUST be sent
>>back
>>directly in the response to the Reliable Message. This pattern is not
>>applicable for one-way application level MEP. The acknowledgment
>>message that can be sent back in the response is for the message in the
>>request only. Acknowledgment message for the former request
>>MUST NOT be sent back.
>>“
>>
>>To allow the receiving RMP to return acks or falts for former requests,
>>the last two sentences are too strong:
>>    
>>
>
> I believe I mentioned this many times so far, there is no mechanism to
> to identify a Sender in a standard way in either the Response or Poll case.
>
The group id is globally unique. IF extra info from the past is 
returned, the sender could ignore the extra stuff it it does not
know about these groups. However, in many cases the sender might be 
happy to get this outstandin ack and rault information.

The receving RMP does not have to use it.

>
>  
>
>>Replace the last two sentence in the above quoted text with the following:
>>“
>>Acknolwedgements or RM fault indications for former requests MAY also be
>>included in the response,
>>if they were unable to be returned in their own responses.
>>
>>    
>>
>
> -1.
>
> In R-R case, when the Sender doesn't receive a response, they will
> generally do a retry. So I don't see a need to support this use case.
>

If the ack was not able to be sent due to lost transport connection, 
then the receving rmp may want to
send the ack with the response to a future reliable message.

>  
>
>>NOTE: In cases where the underlying transport connection is not
>>available to return an Acknolwedgement or RM fault, a Receiving RMP MAY
>>include that Acknowledgement or RM fault with the response to a future
>>reliable message request with the same GroupID.
>>“
>>
>>    
>>
>
> -1.
>
> As I mentioned in one of the con. call, 2 different nodes can share the
> same groupId and be part of the same group. In such case, there is no
> guarantee that subsequent "acks" will go back to the original and destined
> Sender.
>  
>
This is a difficult scenario to swallow. How could they coordinate the 
sequential use of sequnce numberin if they are
not in close coordination for the group?

>
>  
>
>>--
>>----------------------------------------------------
>>Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
>>Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>
>>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>>    
>>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>
>  
>


-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133