[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: TPA and ebXML Header question
Shimamura-san, Thank you for clarifying the example. I now understand that in general, deadlock will not happen. I have one more question. You said: Here is condition which causes retry sequence in the Sender: - First message in the window: - detection of timeout - window is full Is the above condition an OR condition or an AND condition? If the condition is "detection of timeout OR window is full", there should not be a deadlock. If it is "detection of timeout AND window is full", deadlock is possible if there are not enough outgoing messages to fill the window. Regards, Martin Sachs ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* SHIMAMURA Masayoshi <shima@rp.open.cs.fujitsu.co.jp> on 10/27/2000 07:27:35 AM To: Martin W Sachs/Watson/IBM@IBMUS, ebxml-transport@lists.ebxml.org cc: ebxml-tp@lists.ebxml.org 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]
Powered by eList eXpress LLC