Hi
Thomas, thank you for information regarding issue #2. I filed CR0001164.
Anyone can help me with issues #1 and #3?
Best regards
Mateusz
>
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: Wednesday, April 25, 2007 2:09 PM
>To:
This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: TCI CH
>
>Hello Mateusz,
>
>I have not been working a lot with tci-CH, but when looking
>your issue 2 I agree with your analysis. Describing more
>precisely what 'reset' actually means as part of the actions
>for tciReset, e.g. stoping the test components, would resolve
>this issue. Then also the additional calls to
>tciStopTestComponent can be removed from the diagrams you
>mentioned. Would it be ok if you prepare a corresponding CR,
>see
www.ttcn-3.org/ChangeRequest.htm ?
>
>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. |
>
>
>
>
>>
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, 23. April 2007 14:27
>>To:
This email address is being protected from spambots. You need JavaScript enabled to view it.
>>Subject: TCI CH
>>
>>Hi
>>
>>I tried to prototype CH module recently. When I studied
>>chapter 11 - "Use scenarios" of TCI spec I encountered some
>>problems. I wonder if you can help me with them?
>>
>>1. Control behaviour
>>
>>I always thought that CH is responsible for handling
>>geographicaly distributed TTCN components. All data that I
>>need to pass to initialize such a module is i.e. names of
>>components and their IP addresses/UDP ports. Based on that
>>info CH module will find out if TTCN component is local for TE
>>or a remote one. I also found a statement at the end of
>>6.1.1.3 "The CH does not implement the TTCN-3 component behaviour."
>>
>>Figures 16 and 17 specifies that CH needs to initialize
>>control component behaviour though.
>>
>>Shouldn't TE call tciStartTestComponentReq(control,
>>controlbeh, null) and assign control behaviour specified in
>>current TTCN-3 module? How CH knows what behaviour should be
>>assigned to control part?
>>
>>
>>2. tciReset procedure
>>
>>We can see on Figures 24 and 27 that tciStopTestComponent() is
>>called by TCI_CH_Provided when tciResetReq() is received. I
>>think it is bad
>>because:
>>a) It means that CH does not need to monitor only active
>>connections but also should be aware what test components are
>>still alive. So it needs to duplicate what TE already does.
>>b) Description of tciStopTestComponent() says that it is run only when
>>tciStopTestComponentReq() is received by CH.
>>c) tciStopTestComponentReq() is not used on any figure in
>specification
>>d) tciResetReq() is ment to "transmit the reset request to all
>>involeved TEs" according to its descritpion.
>>
>>Shouldn't TE call tciStopTestComponentReq() explicitly before
>>calling tciResetReq()?
>>
>>
>>3. Figure 21
>>
>>Figure 21 specifies that tciTestComponentTerminated(ptc,
>>localPTCVerdict) is called only on special TE. Shouldn't it be
>>called also on MTC (I think that it should know that created
>>PTC has ended)?
>>Description of tciTestComponentTerminatedReq() says that it
>>should distribute information to all participating TEs.
>>
>>
>>
>>I think I am not aware of some information or there are bugs
>>in standard specification?
>>
>>
>>Best regards
>>
>>Mateusz Pusz
>>
>
