Hi all,

During prototyping of CH behavior I found a problem that I cannot solve
by myself. Can you help me?

In the following scenario I base on "TCI" and "TTCN-3 Operational
Semantics" specifications:
1. Run test case on an environment with 3 separate TEs: TE1, TE2, TE3
2. Start MTC on TE1
3. MTC creates PTC1 on TE2 (CH provides TriComponentId to MTC)
4. PTC1 creates PTC2 on TE2 or TE3 (CH provides TriComponentId to PTC2
but not to MTC -> TE1 ALL-ENTITY-STATES not affected).
5. MTC calls "all component.stop"
6. <stop-all-comp> is called on TE1 and runs <stop-alive-component> on
every entity from ALL-ENTITY-STATES
7. <stop-alive-component> does not stop components created by those
entities so PTC2 lives ;-(

The problem is that:
- MTC does not know TriComponentId of PTC2 component because it was
reported only to PTC1
- PTC2 is not stopped with PTC1

How to make above scenario work?

Best Regards

Mateusz Pusz

Hello Mateusz,

Thanks for pointing this out.

I have not been working myself on distributed test execution, therefore the explanations below are based on just trying to understand the standard. Maybe someone who worked on distributed execution could comment, too.

According to the operational semantics ALL-ENTITY-STATES is updated when PTC1 creates PTC2. The following line is from the flow-graph of the create operation:

ALL-ENTITY-STATES.append(newEntityState);

Now, when stopping all components, the states of both PTC1 and PTC2 are contained in ALL-ENTITY-STATES and can be stopped.

This semantics has to be achieved by a TTCN-3 runtime system, including an implementation of the CH. Whether there is just one TE (no distribution) or several TEs (distributed execution) must not matter.

Effectively, this makes ALL-ENTITY-STATES a global variable in a distributed systems. In my understanding it is the task of the CH implementation to make this happen. The CH, considered as a single entity across the hosts on which the test system is executing, does have the necessary information about component ids and could stop all the components if requested to do so. Actually the problem might be at this point. The MTC (and the corresponding TE1) do not have a TCI operation to stop all components. There is an operation to stop a single component that can be called by TE1. By iterating over all components known on TE1, PTC1 on TE2 can be stopped. But as PTC2 is not known on TE1, it cannot be stopped.

To get this working a change of the standard would be needed. I can see two ways to do so:
1) Add an operation to forward the id of a newly created component to the TE where the MTC (or control?) is residing, such that this TE can do the necessary bookkeeping.
2) Extend the tciStopTestComponentReq such that it can request the CH to stop all components in a single operation, or provide a separate operation for this.

I would prefer case 2), leaving it to the CH to establish the semantics. It should not be the TE of the MTC iterating over all known component ids. Are there other opinions out there?

These explanations are based on edition 3.2.1 of the standard. And obviously one would have to check whether a similar problem occurs for operations which might refer to all components.

Best regards

Thomas

---

| Thomas Deiß, Nokia Research Center Street address: |
| P.O. Box 101823 Meesmannstrasse 103 |
| D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
| Phone: +49 234 984 2217, Mobile: +49 163 984 2217 |
| Fax: +49 234 984 3491, E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

>Sitz der Nokia GmbH: Bochum * Amtsgericht Bochum:HRB 4112 * Umsatzsteueridentifikationsnummer: DE 811163 495 * WEEE-Reg.-Nr. DE 51797011* Vorsitzender des Aufsichtsrates: Veli Sundbäck * Geschäftsführer: Timo Elonen, Klaus Goll, Dr. Ulrich Halka, Razvan Olosu (Sprecher), Karsten Schilly
>
Der Netzwerkbereich der Nokia GmbH arbeitet auf Rechnung von Nokia Siemens Networks.


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
>Pusz, Mateusz
>Sent: Thursday, 17. May 2007 14:38
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: PTC test component lifetime
>
>Hi all,
>
>During prototyping of CH behavior I found a problem that I
>cannot solve by myself. Can you help me?
>
>In the following scenario I base on "TCI" and "TTCN-3
>Operational Semantics" specifications:
>1. Run test case on an environment with 3 separate TEs: TE1,
>TE2, TE3 2. Start MTC on TE1 3. MTC creates PTC1 on TE2 (CH
>provides TriComponentId to MTC) 4. PTC1 creates PTC2 on TE2 or
>TE3 (CH provides TriComponentId to PTC2 but not to MTC -> TE1
>ALL-ENTITY-STATES not affected).
>5. MTC calls "all component.stop"
>6. <stop-all-comp> is called on TE1 and runs
><stop-alive-component> on every entity from ALL-ENTITY-STATES
>7. <stop-alive-component> does not stop components created by
>those entities so PTC2 lives ;-(
>
>The problem is that:
>- MTC does not know TriComponentId of PTC2 component because
>it was reported only to PTC1
>- PTC2 is not stopped with PTC1
>
>How to make above scenario work?
>
>Best Regards
>
>Mateusz Pusz
>

Hi,

Thomas, thank you for your answer. Your explanation was very helpful. It also proofed that it is an open issue. I think that your sugestion No. 1 is a better solution. I think so because:

1. Every PTC can stop MTC component so TriComponentId of MTC should be available also on every TE. One can of course use predefined 'MTC' compName to target MTC component but it is written that it should not be considered an unique identifier (user can create other PTCs with name 'MTC' assigned).

2. MTC component can call "all component.stop" or "all component.kill" any time. It should know a kind of created components to distinguish ALIVE components.

2. If ALL-ENTITY-STATES is considered to be a global variable in a test system than all participating TEs should know all TriComponentIds of all created components (CONTROL component is ment to be the first on the list).


I think that a new CH call should be added. It can be similar in form and behavior to 'tciTestComponentTerminatedReq()'. It should be broadcasted to all TEs after creation of each component. The arguments should contain 'TriComponentId' of created component and its 'kind'. So ANSI C definitions of CH calls can look like that:

tciTestComponentCreatedReq(TriComponentId component, TciTestComponentKindType kind);
tciTestComponentCreated(TriComponentId component, TciTestComponentKindType kind);

What do you think about that?

Best Regards

Mateusz Pusz


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Thomas Deiss
>Sent: Friday, May 18, 2007 8:51 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: PTC test component lifetime
>
>Hello Mateusz,
>
>Thanks for pointing this out.
>
>I have not been working myself on distributed test execution,
>therefore the explanations below are based on just trying to
>understand the standard. Maybe someone who worked on
>distributed execution could comment, too.
>
>According to the operational semantics ALL-ENTITY-STATES is
>updated when PTC1 creates PTC2. The following line is from the
>flow-graph of the create operation:
>
>ALL-ENTITY-STATES.append(newEntityState);
>
>Now, when stopping all components, the states of both PTC1 and
>PTC2 are contained in ALL-ENTITY-STATES and can be stopped.
>
>This semantics has to be achieved by a TTCN-3 runtime system,
>including an implementation of the CH. Whether there is just
>one TE (no distribution) or several TEs (distributed
>execution) must not matter.
>
>Effectively, this makes ALL-ENTITY-STATES a global variable in
>a distributed systems. In my understanding it is the task of
>the CH implementation to make this happen. The CH, considered
>as a single entity across the hosts on which the test system
>is executing, does have the necessary information about
>component ids and could stop all the components if requested
>to do so. Actually the problem might be at this point. The MTC
>(and the corresponding TE1) do not have a TCI operation to
>stop all components. There is an operation to stop a single
>component that can be called by TE1. By iterating over all
>components known on TE1, PTC1 on TE2 can be stopped. But as
>PTC2 is not known on TE1, it cannot be stopped.
>
>To get this working a change of the standard would be needed.
>I can see two ways to do so:
>1) Add an operation to forward the id of a newly created
>component to the TE where the MTC (or control?) is residing,
>such that this TE can do the necessary bookkeeping.
>2) Extend the tciStopTestComponentReq such that it can request
>the CH to stop all components in a single operation, or
>provide a separate operation for this.
>
>I would prefer case 2), leaving it to the CH to establish the
>semantics. It should not be the TE of the MTC iterating over
>all known component ids. Are there other opinions out there?
>
>These explanations are based on edition 3.2.1 of the standard.
>And obviously one would have to check whether a similar
>problem occurs for operations which might refer to all components.
>
>Best regards
>
>Thomas
>

---

>| Thomas Deiß, Nokia Research Center Street address: |
>| P.O. Box 101823 Meesmannstrasse 103 |
>| D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
>| Phone: +49 234 984 2217, Mobile: +49 163 984 2217 |
>| Fax: +49 234 984 3491, E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |
>

---

>
>>Sitz der Nokia GmbH: Bochum * Amtsgericht Bochum:HRB 4112 *
>Umsatzsteueridentifikationsnummer: DE 811163 495 *
>WEEE-Reg.-Nr. DE 51797011* Vorsitzender des Aufsichtsrates:
>Veli Sundbäck * Geschäftsführer: Timo Elonen, Klaus Goll, Dr.
>Ulrich Halka, Razvan Olosu (Sprecher), Karsten Schilly
>>
>Der Netzwerkbereich der Nokia GmbH arbeitet auf Rechnung von
>Nokia Siemens Networks.
>
>
>>

---

Original Message

---

>>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
>>Pusz, Mateusz
>>Sent: Thursday, 17. May 2007 14:38
>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>Subject: PTC test component lifetime
>>
>>Hi all,
>>
>>During prototyping of CH behavior I found a problem that I
>>cannot solve by myself. Can you help me?
>>
>>In the following scenario I base on "TCI" and "TTCN-3
>>Operational Semantics" specifications:
>>1. Run test case on an environment with 3 separate TEs: TE1,
>>TE2, TE3 2. Start MTC on TE1 3. MTC creates PTC1 on TE2 (CH
>>provides TriComponentId to MTC) 4. PTC1 creates PTC2 on TE2 or
>>TE3 (CH provides TriComponentId to PTC2 but not to MTC -> TE1
>>ALL-ENTITY-STATES not affected).
>>5. MTC calls "all component.stop"
>>6. <stop-all-comp> is called on TE1 and runs
>><stop-alive-component> on every entity from ALL-ENTITY-STATES
>>7. <stop-alive-component> does not stop components created by
>>those entities so PTC2 lives ;-(
>>
>>The problem is that:
>>- MTC does not know TriComponentId of PTC2 component because
>>it was reported only to PTC1
>>- PTC2 is not stopped with PTC1
>>
>>How to make above scenario work?
>>
>>Best Regards
>>
>>Mateusz Pusz
>>
>

Hello Mateusz,

In my opinion the main difference among the two proposals is where the information about the created test components is stored. As I see it:

1) The information is stored in the TE that contains the MTC. This implies that all changes about the status of PTCs have to be forwarded to this TE.

2) The information is stored somewhere in the CH. Whether this is done on one host or whether this is distributed over several ones is left open. Obviously it is also possible to store the information in that part of the CH that is on the same host as the MTC.

I think that in both cases it is not easy to maintain this information in a consistent way, taking care that there are neither deadlocks nor race conditions. Whether ALL-ENTITY-STATES is maintained as a single global variable or whether it is distributed over the system is left open by the standard. Nevertheless there are implications on how this variable can be accessed.

My preference is 2) because this leaves more options for implementation. Also, the number of TCI operations does not increase (note that we might need similar operations for stop, done, alive, ...), but this is not a major issues.

Other opinions are still welcome.

Best regards

Thomas




>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
>Pusz, Mateusz
>Sent: Monday, 21. May 2007 08:31
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: PTC test component lifetime
>
>Hi,
>
>Thomas, thank you for your answer. Your explanation was very
>helpful. It also proofed that it is an open issue. I think
>that your sugestion No. 1 is a better solution. I think so because:
>
>1. Every PTC can stop MTC component so TriComponentId of MTC
>should be available also on every TE. One can of course use
>predefined 'MTC' compName to target MTC component but it is
>written that it should not be considered an unique identifier
>(user can create other PTCs with name 'MTC' assigned).
>
>2. MTC component can call "all component.stop" or "all
>component.kill" any time. It should know a kind of created
>components to distinguish ALIVE components.
>
>2. If ALL-ENTITY-STATES is considered to be a global variable
>in a test system than all participating TEs should know all
>TriComponentIds of all created components (CONTROL component
>is ment to be the first on the list).
>
>
>I think that a new CH call should be added. It can be similar
>in form and behavior to 'tciTestComponentTerminatedReq()'. It
>should be broadcasted to all TEs after creation of each
>component. The arguments should contain 'TriComponentId' of
>created component and its 'kind'. So ANSI C definitions of CH
>calls can look like that:
>
>tciTestComponentCreatedReq(TriComponentId component,
>TciTestComponentKindType kind);
>tciTestComponentCreated(TriComponentId component,
>TciTestComponentKindType kind);
>
>What do you think about that?
>
>Best Regards
>
>Mateusz Pusz
>
>
>>

---

Original Message

---

>>From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
>>[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Thomas Deiss
>>Sent: Friday, May 18, 2007 8:51 AM
>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>Subject: Re: PTC test component lifetime
>>
>>Hello Mateusz,
>>
>>Thanks for pointing this out.
>>
>>I have not been working myself on distributed test execution,
>therefore
>>the explanations below are based on just trying to understand the
>>standard. Maybe someone who worked on distributed execution could
>>comment, too.
>>
>>According to the operational semantics ALL-ENTITY-STATES is updated
>>when PTC1 creates PTC2. The following line is from the flow-graph of
>>the create operation:
>>
>>ALL-ENTITY-STATES.append(newEntityState);
>>
>>Now, when stopping all components, the states of both PTC1 and
>>PTC2 are contained in ALL-ENTITY-STATES and can be stopped.
>>
>>This semantics has to be achieved by a TTCN-3 runtime system,
>including
>>an implementation of the CH. Whether there is just one TE (no
>>distribution) or several TEs (distributed
>>execution) must not matter.
>>
>>Effectively, this makes ALL-ENTITY-STATES a global variable in a
>>distributed systems. In my understanding it is the task of the CH
>>implementation to make this happen. The CH, considered as a single
>>entity across the hosts on which the test system is executing, does
>>have the necessary information about component ids and could stop all
>>the components if requested to do so. Actually the problem
>might be at
>>this point. The MTC (and the corresponding TE1) do not have a TCI
>>operation to stop all components. There is an operation to stop a
>>single component that can be called by TE1. By iterating over all
>>components known on TE1, PTC1 on TE2 can be stopped. But as
>>PTC2 is not known on TE1, it cannot be stopped.
>>
>>To get this working a change of the standard would be needed.
>>I can see two ways to do so:
>>1) Add an operation to forward the id of a newly created component to
>>the TE where the MTC (or control?) is residing, such that this TE can
>>do the necessary bookkeeping.
>>2) Extend the tciStopTestComponentReq such that it can request the CH
>>to stop all components in a single operation, or provide a separate
>>operation for this.
>>
>>I would prefer case 2), leaving it to the CH to establish the
>>semantics. It should not be the TE of the MTC iterating over
>all known
>>component ids. Are there other opinions out there?
>>
>>These explanations are based on edition 3.2.1 of the standard.
>>And obviously one would have to check whether a similar
>problem occurs
>>for operations which might refer to all components.
>>
>>Best regards
>>
>>Thomas
>>

---

>>| Thomas Deiß, Nokia Research Center Street address: |
>>| P.O. Box 101823 Meesmannstrasse 103 |
>>| D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
>>| Phone: +49 234 984 2217, Mobile: +49 163 984 2217 |
>>| Fax: +49 234 984 3491, E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |
>>

---

>>
>>>Sitz der Nokia GmbH: Bochum * Amtsgericht Bochum:HRB 4112 *
>>Umsatzsteueridentifikationsnummer: DE 811163 495 * WEEE-Reg.-Nr. DE
>>51797011* Vorsitzender des Aufsichtsrates:
>>Veli Sundbäck * Geschäftsführer: Timo Elonen, Klaus Goll, Dr.
>>Ulrich Halka, Razvan Olosu (Sprecher), Karsten Schilly
>>>
>>Der Netzwerkbereich der Nokia GmbH arbeitet auf Rechnung von Nokia
>>Siemens Networks.
>>
>>
>>>

---

Original Message

---

>>>From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
>>>[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext Pusz, Mateusz
>>>Sent: Thursday, 17. May 2007 14:38
>>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>>Subject: PTC test component lifetime
>>>
>>>Hi all,
>>>
>>>During prototyping of CH behavior I found a problem that I cannot
>>>solve by myself. Can you help me?
>>>
>>>In the following scenario I base on "TCI" and "TTCN-3 Operational
>>>Semantics" specifications:
>>>1. Run test case on an environment with 3 separate TEs: TE1,
>TE2, TE3
>>>2. Start MTC on TE1 3. MTC creates PTC1 on TE2 (CH provides
>>>TriComponentId to MTC) 4. PTC1 creates PTC2 on TE2 or
>>>TE3 (CH provides TriComponentId to PTC2 but not to MTC -> TE1
>>>ALL-ENTITY-STATES not affected).
>>>5. MTC calls "all component.stop"
>>>6. <stop-all-comp> is called on TE1 and runs
><stop-alive-component> on
>>>every entity from ALL-ENTITY-STATES 7.
><stop-alive-component> does not
>>>stop components created by those entities so PTC2 lives ;-(
>>>
>>>The problem is that:
>>>- MTC does not know TriComponentId of PTC2 component because it was
>>>reported only to PTC1
>>>- PTC2 is not stopped with PTC1
>>>
>>>How to make above scenario work?
>>>
>>>Best Regards
>>>
>>>Mateusz Pusz
>>>
>>
>