OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: TPA and ebXML Header question


Mr. Martin W Sachs, 

On Thu, 26 Oct 2000 09:23:47 -0400
"Martin W Sachs/Watson/IBM" <mwsachs@us.ibm.com> wrote:
> 
> Regarding deadlocks, I have some questions and comments.
> 
> The example shows a fixed window size of 4.  Who or what determines the
> window size?
> 

One possible idea is that the window size is determined by system
administrator and then it is specified in TPA.

One of most important factor to determine the window size is
communication performance between the Sender and the Receiver. Following
simple model and formula can be used as a sample to determine the window
size.

+--------+                      +--------+
| Sender +--------Message------>|Receiver|
|        | A                    |        |
|        | |                    |        |
|        | |T[s]                |        |
|        | |                    |        |
|        | V                    |        |
|        |<-------Message(Ack)--+        |
+--------+                      +--------+

- Turn around time:  T [s]
- Data rate:  S [bit/s]
- Length of the Message:  M [bit]
- Window Size:  W = (T * S) / M

> What is in a single window?
>      Only messages for one conversation?
>      Only messages for one pair of application instances?

The window has not any relationship with application level semantics.

>      All messages going on the same outbound link?
> 

Yes.

> What happens if application-level responses are owed to all sent messages
> but there aren't enough sent messages to fill the window?
> I believe the answer is: deadlock, but I may not have understood something
> in this proposal.
> 

Here is condition which causes retry sequence in the Sender:

  - First message in the window:
      - detection of timeout
      - window is full

  - Other messages except the first message in the window:
      - detection of timeout

Thus even if there are not enough sent messages to fill the window, the
Sender initiates retry sequence when the Sender detects timeout.

> Example 1 shows that the sending message service waits until the window is
> filled before attempting to retry message 3.  If that is correct, then it
> will deadlock if there aren't enough outgoing messages to fill the window.

In the example, if the window does not become full, the Sender will
detect timeout of Ack of message 3. Here is modification of the
example:

   ------------------------------------------------
    Ex. 3 (modification of Ex.1) [Window Size = 4]
   ------------------------------------------------
    [Sender]                  [Receiver]
    Seq No.1      ----------> Passed to App
    Ack for No.1 <----------
    
    Seq No.2      ----------> Passed to App
    Ack for No.2 <----------
    
    Seq No.3     ---> LOST                     A
                                               |
    [the Sender detects timeout                |
     of ack of sent message No.3               | Window (size = 4)
     and initiates retry]                      |
                                               |
    Seq No.3 (retry) -------> Passed to App    |
    Ack for No.3 <----------                   |
                                               |
    [no next message]           [the window does not become full
                                 but all the messages reach the Receiver]


Regards, 

--
SHIMAMURA Masayoshi
E-mail: shima@rp.open.cs.fujitsu.co.jp
TEL:+81-45-476-4590(ext.7128-4241)  FAX:+81-45-476-4726(ext.7128-6783)
Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC