TOPIC:

Hi everybody,

I have a question regarding the TTCN-3 port definition.
quoted from sect 8.1:
"
Connections among components and between a component and the test system interface are port-oriented. Each port is modelled as an infinite FIFO queue which stores the incoming messages or procedure calls until they are processed by the component owning that port.
"
My question is: once a port(connecting a test component and the test system interface)
is mapped, should it be always "open" for receiving messages from the IUT until an explicit
unmap operation?

Someone augues that by using "Receive" operation, we actually mean "receive a message emitted
by the IUT at the time when Receive operation is executed or after that". If this is true,
I think that all the messages in the a port should be timestamped, and then the matching of
an Receive operation should consider timestamps. Should messages coming before the time when
the Receive operation is executed be discarded (not used for matching)?

I do not know if this is relevant to synchronous test and asynchronous test.
---
Best Regards,

Zhongjie Li

********************************************************************
* Zhongjie Li *
* Ph.D candidate, Department of Computer Science & Technology *
* Tsinghua University, Beijing, 100084, P.R.China *
* Tel: +86+10-62788109 Fax: +86+10-62788109 *
* Email: This email address is being protected from spambots. You need JavaScript enabled to view it. *
********************************************************************

Dear Zhongjie,

The "receive" operation is defined on the component port queue, and the
map operation defines when the port queues can receive something from
the test system interface, i.e. when it is mapped. So WHEN a message has
been sent by the IUT is more or less irrelevant. Only the presence in
the component port queue is relevant.

In other words, the receive operation looks at the component port queue,
reads the first the message of the queue, if any and tries to match it.
On successful matching it removes the message from the queue.

Please keep in mind also the snapshot semantics of TTCN-3, i.e. that at
the beginning of an alternative ALL port and timer queues will be
frozen, until all receive/timeout statements have been evaluated.

Taken all this into account, an additional semantics with time stamping
of messages in queue is not needed. Just freeze the queue content at the
beginning of a set of alternatives.

With best regards,

Theo Vassiliou

Li Zhongjie schrieb:
> Hi everybody,
>
> I have a question regarding the TTCN-3 port definition. quoted from
> sect 8.1: " Connections among components and between a component and
> the test system interface are port-oriented. Each port is modelled as
> an infinite FIFO queue which stores the incoming messages or
> procedure calls until they are processed by the component owning that
> port. " My question is: once a port(connecting a test component and
> the test system interface) is mapped, should it be always "open" for
> receiving messages from the IUT until an explicit unmap operation?
>
> Someone augues that by using "Receive" operation, we actually mean
> "receive a message emitted by the IUT at the time when Receive
> operation is executed or after that". If this is true, I think that
> all the messages in the a port should be timestamped, and then the
> matching of an Receive operation should consider timestamps. Should
> messages coming before the time when the Receive operation is
> executed be discarded (not used for matching)?
>
> I do not know if this is relevant to synchronous test and
> asynchronous test. --- Best Regards,
>
> Zhongjie Li
>
> ********************************************************************
> * Zhongjie Li *
> * Ph.D candidate, Department of Computer Science & Technology *
> * Tsinghua University, Beijing, 100084, P.R.China *
> * Tel: +86+10-62788109 Fax: +86+10-62788109 *
> * Email: This email address is being protected from spambots. You need JavaScript enabled to view it. *
> ********************************************************************


--

---

Theofanis Vassiliou-Gioles Testing Technologies IST
Oranienburger Str. 65 The TTCN-3 Company
10117 Berlin, Germany phone +49 30 726 19 19 0
This email address is being protected from spambots. You need JavaScript enabled to view it. DDI +49 30 726 19 19 12
www.testingtech.de fax +49 30 726 19 19 20

Hi again,

Here is a reply on my own mail.
I just want to make sure not be misunderstood. ;-)

> Please keep in mind also the snapshot semantics of TTCN-3, i.e. that
> at the beginning of an alternative ALL port and timer queues will be
> frozen, until all receive/timeout statements have been evaluated.

Just the *first* element, if any, of a queue will be frozen in a
snapshot. Of course, while a snapshot is in progress new messages can
arrive at the port queue. This new message will be then evaluated at the
next snapshot.

Best regards,

Theo


Theofanis Vassiliou-Gioles schrieb:
> Dear Zhongjie,
>
> The "receive" operation is defined on the component port queue, and
> the map operation defines when the port queues can receive something
> from the test system interface, i.e. when it is mapped. So WHEN a
> message has been sent by the IUT is more or less irrelevant. Only the
> presence in the component port queue is relevant.
>
> In other words, the receive operation looks at the component port
> queue, reads the first the message of the queue, if any and tries to
> match it. On successful matching it removes the message from the
> queue.
>
> Please keep in mind also the snapshot semantics of TTCN-3, i.e. that
> at the beginning of an alternative ALL port and timer queues will be
> frozen, until all receive/timeout statements have been evaluated.
>
> Taken all this into account, an additional semantics with time
> stamping of messages in queue is not needed. Just freeze the queue
> content at the beginning of a set of alternatives.
>
> With best regards,
>
> Theo Vassiliou
>
> Li Zhongjie schrieb:
>
>> Hi everybody,
>>
>> I have a question regarding the TTCN-3 port definition. quoted from
>> sect 8.1: " Connections among components and between a component
>> and the test system interface are port-oriented. Each port is
>> modelled as an infinite FIFO queue which stores the incoming
>> messages or procedure calls until they are processed by the
>> component owning that port. " My question is: once a
>> port(connecting a test component and the test system interface) is
>> mapped, should it be always "open" for receiving messages from the
>> IUT until an explicit unmap operation?
>>
>> Someone augues that by using "Receive" operation, we actually mean
>> "receive a message emitted by the IUT at the time when Receive
>> operation is executed or after that". If this is true, I think that
>> all the messages in the a port should be timestamped, and then the
>> matching of an Receive operation should consider timestamps.
>> Should messages coming before the time when the Receive operation
>> is executed be discarded (not used for matching)?
>>
>> I do not know if this is relevant to synchronous test and
>> asynchronous test. --- Best Regards,
>>
>> Zhongjie Li
>>
>> ********************************************************************
>> * Zhongjie Li * * Ph.D candidate, Department of Computer
>> Science & Technology * * Tsinghua University, Beijing, 100084,
>> P.R.China * * Tel: +86+10-62788109 Fax: +86+10-62788109 * *
>> Email: This email address is being protected from spambots. You need JavaScript enabled to view it. *
>> ********************************************************************
>>
>>
>>
>
>
>
> --

---

> Theofanis Vassiliou-Gioles Testing Technologies IST
> Oranienburger Str. 65 The TTCN-3 Company 10117
> Berlin, Germany phone +49 30 726 19 19 0
> This email address is being protected from spambots. You need JavaScript enabled to view it. DDI +49 30 726 19 19 12
> www.testingtech.de fax +49 30 726 19 19 20

Hi theo,
Thank you for your timely response. See my comments in line.

---

Original Message

---

From: "Theofanis Vassiliou-Gioles" <This email address is being protected from spambots. You need JavaScript enabled to view it.>
To: <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Sent: Thursday, October 31, 2002 12:57 AM
Subject: Re: a question about TTCN-3 "port"


> Dear Zhongjie,
>
> The "receive" operation is defined on the component port queue, and the
> map operation defines when the port queues can receive something from
> the test system interface, i.e. when it is mapped. So WHEN a message has
> been sent by the IUT is more or less irrelevant. Only the presence in
> the component port queue is relevant.

I know what you mean. My question came from a practical testing issue.

Suppose I am testing a protocol with TCP as the underlying protocol, then
when should I open the TCP connection, when should I close it? Certainly
this is not defined in the test case only specifying higher layer functions.
If I open the TCP connection in the very start of executing a test case,
and close it after the execution has done, all packets that the IUT send
during the testing process will be accumulated in the relevant port, so
I have to keep in mind that "Receive" operation is not "real-time", and that
I will read "the next PDU in the port" instead of "the PDU the IUT sends out
at the time when Receive option is executed or after that".

Perhaps we can think that TTCN-3 has no restrictions on how to use the
"Receive" operation, and also has no assumptions on what the port is implemented.
Then user can select the semantics they use the Receive operation and implement
ports as needed. That is, they either assume "Receive operation is real-time", or
"Receive operation is asynchronous" (we only discuss this operation in message-based
communication context).

Also for the last example, If the test case writer assume that the Receive operation
is real-time, we must design a communication mechanism that allows real-time control
and observation of the IUT. If the test case writer assume that the Receive operation
is asynchronous, we just open the TCP socket at the start of execution, and close it
after the execution is over.

Is my understanding right?
>
> In other words, the receive operation looks at the component port queue,
> reads the first the message of the queue, if any and tries to match it.
> On successful matching it removes the message from the queue.
>
> Please keep in mind also the snapshot semantics of TTCN-3, i.e. that at
> the beginning of an alternative ALL port and timer queues will be
> frozen, until all receive/timeout statements have been evaluated.
>
> Taken all this into account, an additional semantics with time stamping
> of messages in queue is not needed. Just freeze the queue content at the
> beginning of a set of alternatives.
>
> With best regards,
>
> Theo Vassiliou
>
> Li Zhongjie schrieb:
> > Hi everybody,
> >
> > I have a question regarding the TTCN-3 port definition. quoted from
> > sect 8.1: " Connections among components and between a component and
> > the test system interface are port-oriented. Each port is modelled as
> > an infinite FIFO queue which stores the incoming messages or
> > procedure calls until they are processed by the component owning that
> > port. " My question is: once a port(connecting a test component and
> > the test system interface) is mapped, should it be always "open" for
> > receiving messages from the IUT until an explicit unmap operation?
> >
> > Someone augues that by using "Receive" operation, we actually mean
> > "receive a message emitted by the IUT at the time when Receive
> > operation is executed or after that". If this is true, I think that
> > all the messages in the a port should be timestamped, and then the
> > matching of an Receive operation should consider timestamps. Should
> > messages coming before the time when the Receive operation is
> > executed be discarded (not used for matching)?
> >
> > I do not know if this is relevant to synchronous test and
> > asynchronous test. --- Best Regards,
> >
> > Zhongjie Li
> >
> > ********************************************************************
> > * Zhongjie Li *
> > * Ph.D candidate, Department of Computer Science & Technology *
> > * Tsinghua University, Beijing, 100084, P.R.China *
> > * Tel: +86+10-62788109 Fax: +86+10-62788109 *
> > * Email: This email address is being protected from spambots. You need JavaScript enabled to view it. *
> > ********************************************************************
>
>
> --
>

---

> Theofanis Vassiliou-Gioles Testing Technologies IST
> Oranienburger Str. 65 The TTCN-3 Company
> 10117 Berlin, Germany phone +49 30 726 19 19 0
> This email address is being protected from spambots. You need JavaScript enabled to view it. DDI +49 30 726 19 19 12
> www.testingtech.de fax +49 30 726 19 19 20
>
>

Hello Li,

independent of the semantics of the receive statement you are mentioning, a good point for opening and closing TCP connections are the map and unmap statements. To get rid of messages send by the IUT before the test components are prepared to handle them, you can use the clear statement for ports. I hope this helps.

Best regards

Thomas

---

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

---

>

---

Original Message

---

> From: ext Li Zhongjie [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Thursday, October 31, 2002 2:40 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: a question about TTCN-3 "port"
>
>
> Hi theo,
> Thank you for your timely response. See my comments in line.
>

---

Original Message

---

> From: "Theofanis Vassiliou-Gioles" <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> To: <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> Sent: Thursday, October 31, 2002 12:57 AM
> Subject: Re: a question about TTCN-3 "port"
>
>
> > Dear Zhongjie,
> >
> > The "receive" operation is defined on the component port
> queue, and the
> > map operation defines when the port queues can receive
> something from
> > the test system interface, i.e. when it is mapped. So WHEN
> a message has
> > been sent by the IUT is more or less irrelevant. Only the
> presence in
> > the component port queue is relevant.
>
> I know what you mean. My question came from a practical testing issue.
>
> Suppose I am testing a protocol with TCP as the underlying
> protocol, then
> when should I open the TCP connection, when should I close
> it? Certainly
> this is not defined in the test case only specifying higher
> layer functions.
> If I open the TCP connection in the very start of executing a
> test case,
> and close it after the execution has done, all packets that
> the IUT send
> during the testing process will be accumulated in the
> relevant port, so
> I have to keep in mind that "Receive" operation is not
> "real-time", and that
> I will read "the next PDU in the port" instead of "the PDU
> the IUT sends out
> at the time when Receive option is executed or after that".
>
> Perhaps we can think that TTCN-3 has no restrictions on how
> to use the
> "Receive" operation, and also has no assumptions on what the
> port is implemented.
> Then user can select the semantics they use the Receive
> operation and implement
> ports as needed. That is, they either assume "Receive
> operation is real-time", or
> "Receive operation is asynchronous" (we only discuss this
> operation in message-based
> communication context).
>
> Also for the last example, If the test case writer assume
> that the Receive operation
> is real-time, we must design a communication mechanism that
> allows real-time control
> and observation of the IUT. If the test case writer assume
> that the Receive operation
> is asynchronous, we just open the TCP socket at the start of
> execution, and close it
> after the execution is over.
>
> Is my understanding right?
> >
> > In other words, the receive operation looks at the
> component port queue,
> > reads the first the message of the queue, if any and tries
> to match it.
> > On successful matching it removes the message from the queue.
> >
> > Please keep in mind also the snapshot semantics of TTCN-3,
> i.e. that at
> > the beginning of an alternative ALL port and timer queues will be
> > frozen, until all receive/timeout statements have been evaluated.
> >
> > Taken all this into account, an additional semantics with
> time stamping
> > of messages in queue is not needed. Just freeze the queue
> content at the
> > beginning of a set of alternatives.
> >
> > With best regards,
> >
> > Theo Vassiliou
> >
> > Li Zhongjie schrieb:
> > > Hi everybody,
> > >
> > > I have a question regarding the TTCN-3 port definition.
> quoted from
> > > sect 8.1: " Connections among components and between a
> component and
> > > the test system interface are port-oriented. Each port is
> modelled as
> > > an infinite FIFO queue which stores the incoming messages or
> > > procedure calls until they are processed by the component
> owning that
> > > port. " My question is: once a port(connecting a test
> component and
> > > the test system interface) is mapped, should it be always
> "open" for
> > > receiving messages from the IUT until an explicit unmap operation?
> > >
> > > Someone augues that by using "Receive" operation, we actually mean
> > > "receive a message emitted by the IUT at the time when Receive
> > > operation is executed or after that". If this is true, I
> think that
> > > all the messages in the a port should be timestamped, and then the
> > > matching of an Receive operation should consider
> timestamps. Should
> > > messages coming before the time when the Receive operation is
> > > executed be discarded (not used for matching)?
> > >
> > > I do not know if this is relevant to synchronous test and
> > > asynchronous test. --- Best Regards,
> > >
> > > Zhongjie Li
> > >
> > >
> ********************************************************************
> > > * Zhongjie Li
> *
> > > * Ph.D candidate, Department of Computer Science &
> Technology *
> > > * Tsinghua University, Beijing, 100084, P.R.China
> *
> > > * Tel: +86+10-62788109 Fax: +86+10-62788109
> *
> > > * Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> *
> > >
> ********************************************************************
> >
> >
> > --
> >

---

> > Theofanis Vassiliou-Gioles Testing Technologies IST
> > Oranienburger Str. 65 The TTCN-3 Company
> > 10117 Berlin, Germany phone +49 30 726 19 19 0
> > This email address is being protected from spambots. You need JavaScript enabled to view it. DDI +49 30 726 19 19 12
> > www.testingtech.de fax +49 30 726 19 19 20
> >
> >
>

In einer eMail vom 10/30/02 6:34:00 PM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

HI,

> Just the *first* element, if any, of a queue will be frozen in a
> snapshot. Of course, while a snapshot is in progress new messages can
> arrive at the port queue. This new message will be then evaluated at the
> next snapshot.
>


Just a few more words. The new message will only be evaluated if it is the
first
message in a port queue. Furthermore, a reference to the said port queue must
be present in the current (new) snapshot, for this to have any effect. I
believe.

As Theo correctly indicated, only the 1st/first element of each port queue
will be
looked at. Note that a port can be qualified using the keywords in, out, and
inout
to indicate which messages can be received, sent or both on a given port.

Cheers,

Claude.


> Best regards,
>
> Theo
>