Good morning,

The TTCN-3 Core Language standard makes a statement how mixed ports shall be understood: "A mixed port in TTCN-3 is defined as a shorthand notation for two ports, i.e. a message-based port and a procedure-based port with the same name. At run-time the distinction between the two ports is made by the communication operations." This statement has a strange consequence when receiving messages or accepting procecure calls from a mixed port.

Could somebody please comment whether I understood the following behavior correctly. Thanks.

Assume, there are two components A and B which both have a mixed port P and that the ports P of A and of B are connected. Assume also that A sends first a message m on this port and then calls a procedure p on this port:

A:
P.send(m);
P.call(p) { ... };

On the sending side there is a clear temporal order between sending m and calling p.

Assume now that component B executes an alt statement in which the first alternative matches on p and the second one on m. And assume there is sufficient time to insert both m and p in the queue of the port p at B.

B:
alt {
[] P.getcall(p) { ... };
[] P.receive(m) { ... }
}

Because the message m has been send before the procedure p one might assume that the first alternative to match is the one guarded by the receive statement. But as explained in the standard two ports - both called P - are actually used in this alt statement. One message based, containing m, one procedure based, containing p. Consequently, the first alternative guarded by the getcall statement will be executed.

Again, my question is whether this understanding is correct.

Best regards

Thomas

---

| Thomas Deiß, Nokia Research Center Street address: |
| P.O. Box 101823 Meesmannstraße 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. |

---

Hi Thomas,

the answer is YES, your understanding is correct.

Component B does not know anything about the order
of sending of message m and call p by component A. It
evaluates its alt statement based on an actual snapshot.
If in your case both, m and p are in the snapshot,
only the order of the alternative branches of the
alt statement are relevant, i.e., the 'getcall'
branch will be evaluated before the 'receive' branch.

Hope this helps.

Regards
Jens




Thomas Dei_ schrieb:
>
> Good morning,
>
> The TTCN-3 Core Language standard makes a statement how mixed ports shall be
understood: "A mixed port in TTCN-3 is defined as a shorthand notation for two
ports, i.e. a message-based port and a procedure-based port with the same name.
At run-time the distinction between the two ports is made by the communication
operations." This statement has a strange consequence when receiving messages or
accepting procecure calls from a mixed port.
>
> Could somebody please comment whether I understood the following behavior
correctly. Thanks.
>
> Assume, there are two components A and B which both have a mixed port P and
that the ports P of A and of B are connected. Assume also that A sends first a
message m on this port and then calls a procedure p on this port:
>
> A:
> P.send(m);
> P.call(p) { ... };
>
> On the sending side there is a clear temporal order between sending m and
calling p.
>
> Assume now that component B executes an alt statement in which the first
alternative matches on p and the second one on m. And assume there is sufficient
time to insert both m and p in the queue of the port p at B.
>
> B:
> alt {
> [] P.getcall(p) { ... };
> [] P.receive(m) { ... }
> }
>
> Because the message m has been send before the procedure p one might assume
that the first alternative to match is the one guarded by the receive statement.
But as explained in the standard two ports - both called P - are actually used
in this alt statement. One message based, containing m, one procedure based,
containing p. Consequently, the first alternative guarded by the getcall
statement will be executed.
>
> Again, my question is whether this understanding is correct.
>
> Best regards
>
> Thomas
>
>

---

> | Thomas Deiß, Nokia Research Center Street address: |
> | P.O. Box 101823 Meesmannstraße 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. |
>

---

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

Hi Thomas and others,

I think no definite answer can be given for the specific question. I think what shall be clarified:
1. Is the two-port-with-the-same-name approach really means two ports with separate queues?
I think yes, there should be separate queues.
Though theoretically

Best Regards, György
Szia, Gyuri
============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
intranet: conformancelab.ericsson.se
personal: www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Thomas Deiß [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Wednesday, March 27, 2002 8:17 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Mixed ports
>
>
>Good morning,
>
>The TTCN-3 Core Language standard makes a statement how mixed
>ports shall be understood: "A mixed port in TTCN-3 is defined
>as a shorthand notation for two ports, i.e. a message-based
>port and a procedure-based port with the same name. At
>run-time the distinction between the two ports is made by the
>communication operations." This statement has a strange
>consequence when receiving messages or accepting procecure
>calls from a mixed port.
>
>Could somebody please comment whether I understood the
>following behavior correctly. Thanks.
>
>Assume, there are two components A and B which both have a
>mixed port P and that the ports P of A and of B are connected.
>Assume also that A sends first a message m on this port and
>then calls a procedure p on this port:
>
>A:
>P.send(m);
>P.call(p) { ... };
>
>On the sending side there is a clear temporal order between
>sending m and calling p.
>
>Assume now that component B executes an alt statement in which
>the first alternative matches on p and the second one on m.
>And assume there is sufficient time to insert both m and p in
>the queue of the port p at B.
>
>B:
>alt {
> [] P.getcall(p) { ... };
> [] P.receive(m) { ... }
>}
>
>Because the message m has been send before the procedure p one
>might assume that the first alternative to match is the one
>guarded by the receive statement. But as explained in the
>standard two ports - both called P - are actually used in this
>alt statement. One message based, containing m, one procedure
>based, containing p. Consequently, the first alternative
>guarded by the getcall statement will be executed.
>
>Again, my question is whether this understanding is correct.
>
>Best regards
>
>Thomas
>
>
>
>

---

>| Thomas Deiß, Nokia Research Center Street address: |
>| P.O. Box 101823 Meesmannstraße 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. |
>

---

>

These wicked buttons... My mail went unfinished. Sorry for that. So, I try to finish it this time.


Hi Thomas and others,

I think no definite answer can be given for the specific question. I think what shall be clarified:
1) Is the two-port-with-the-same-name approach really means two virtual ports with separate queues?
I think yes, there should be separate queues.
2) If 1) is true, the answer is independent if we have a mixed port or two separate ports with different names. Theoretically the branch receiving m should be chosen. In practical terms there may be a racing condition and the tool may not be able to decide which event was the first - both may be registered by the same snapshot. In this case either alternatives may be chosen (the receive branch will be chosen if the tool is able to say, this was the first).

Best Regards, György
============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
intranet: conformancelab.ericsson.se
personal: www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Thomas Deiß [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Wednesday, March 27, 2002 8:17 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Mixed ports
>
>
>Good morning,
>
>The TTCN-3 Core Language standard makes a statement how mixed
>ports shall be understood: "A mixed port in TTCN-3 is defined
>as a shorthand notation for two ports, i.e. a message-based
>port and a procedure-based port with the same name. At
>run-time the distinction between the two ports is made by the
>communication operations." This statement has a strange
>consequence when receiving messages or accepting procecure
>calls from a mixed port.
>
>Could somebody please comment whether I understood the
>following behavior correctly. Thanks.
>
>Assume, there are two components A and B which both have a
>mixed port P and that the ports P of A and of B are connected.
>Assume also that A sends first a message m on this port and
>then calls a procedure p on this port:
>
>A:
>P.send(m);
>P.call(p) { ... };
>
>On the sending side there is a clear temporal order between
>sending m and calling p.
>
>Assume now that component B executes an alt statement in which
>the first alternative matches on p and the second one on m.
>And assume there is sufficient time to insert both m and p in
>the queue of the port p at B.
>
>B:
>alt {
> [] P.getcall(p) { ... };
> [] P.receive(m) { ... }
>}
>
>Because the message m has been send before the procedure p one
>might assume that the first alternative to match is the one
>guarded by the receive statement. But as explained in the
>standard two ports - both called P - are actually used in this
>alt statement. One message based, containing m, one procedure
>based, containing p. Consequently, the first alternative
>guarded by the getcall statement will be executed.
>
>Again, my question is whether this understanding is correct.
>
>Best regards
>
>Thomas
>
>
>
>

---

>| Thomas Deiß, Nokia Research Center Street address: |
>| P.O. Box 101823 Meesmannstraße 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. |
>

---

>

Hi Gyorgy, Thomas and others,

two ports with the same name really means two ports with the same name.
The distinction between the two ports is made on the receiving side by
the receiving operations: RECEIVE, TRIGGER, GETCALL, GETREPLY, CATCH and
CHECK (with the exception of CHECK ANY, see below), and on the sending
side by the sending operations: SEND, CALL, REPLY and RAISE.

The port operations START, STOP and CLEAR will manipulate both ports
at the same time and the CHECK ANY operation (e.g., Myport.CHECK) will
check both ports for any message, call, reply or exception.

The decision that a mixed port is represented by one message-based and
one procedure-based port was made at one of the first editing meetings
of TTCN-3. The original proposal was to allow message-based and
procedure-base ports only, but no mixed ports. This leads to some
controversal discussions with 'SDL people', because the connection of
TTCN-3 with SDL systems would be a little bit tricky. As a compromise,
it was decided to introduce mixed ports as shorthand for two ports and
to distinguish between the message-based and the procedure-based port
on the operation level.

(Don't blame me for my wording, it is only a very short explanation for
the current mixed port-definition in the standard. There were
some other reasons related to blocking an non-blocking communication,
but I don't remember all these reasons.)

Best regards
Jens Grabowski


"Gyorgy Rethy (ETH)" schrieb:
>
> These wicked buttons... My mail went unfinished. Sorry for that. So, I try to
finish it this time.
>
> Hi Thomas and others,
>
> I think no definite answer can be given for the specific question. I think
what shall be clarified:
> 1) Is the two-port-with-the-same-name approach really means two virtual ports
with separate queues?
> I think yes, there should be separate queues.
> 2) If 1) is true, the answer is independent if we have a mixed port or two
separate ports with different names. Theoretically the branch receiving m
should be chosen. In practical terms there may be a racing condition and the
tool may not be able to decide which event was the first - both may be
registered by the same snapshot. In this case either alternatives may be chosen
(the receive branch will be chosen if the tool is able to say, this was the
first).
>
> Best Regards, György
> ============================================
> dr. György RÉTHY
> Ericsson Communications Systems Hungary Lim.
> Conformance Center
> tel.: +36 1 437-7006; fax: +36 1 437-7767
> mobile: +36 30 297-7862
> e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> intranet: conformancelab.ericsson.se
> personal: www.r.eth.ericsson.se/~ethgry
> ============================================
>
> >

---

Original Message

---

> >From: Thomas Deiß [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> >Sent: Wednesday, March 27, 2002 8:17 AM
> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >Subject: Mixed ports
> >
> >
> >Good morning,
> >
> >The TTCN-3 Core Language standard makes a statement how mixed
> >ports shall be understood: "A mixed port in TTCN-3 is defined
> >as a shorthand notation for two ports, i.e. a message-based
> >port and a procedure-based port with the same name. At
> >run-time the distinction between the two ports is made by the
> >communication operations." This statement has a strange
> >consequence when receiving messages or accepting procecure
> >calls from a mixed port.
> >
> >Could somebody please comment whether I understood the
> >following behavior correctly. Thanks.
> >
> >Assume, there are two components A and B which both have a
> >mixed port P and that the ports P of A and of B are connected.
> >Assume also that A sends first a message m on this port and
> >then calls a procedure p on this port:
> >
> >A:
> >P.send(m);
> >P.call(p) { ... };
> >
> >On the sending side there is a clear temporal order between
> >sending m and calling p.
> >
> >Assume now that component B executes an alt statement in which
> >the first alternative matches on p and the second one on m.
> >And assume there is sufficient time to insert both m and p in
> >the queue of the port p at B.
> >
> >B:
> >alt {
> > [] P.getcall(p) { ... };
> > [] P.receive(m) { ... }
> >}
> >
> >Because the message m has been send before the procedure p one
> >might assume that the first alternative to match is the one
> >guarded by the receive statement. But as explained in the
> >standard two ports - both called P - are actually used in this
> >alt statement. One message based, containing m, one procedure
> >based, containing p. Consequently, the first alternative
> >guarded by the getcall statement will be executed.
> >
> >Again, my question is whether this understanding is correct.
> >
> >Best regards
> >
> >Thomas
> >
> >
> >
> >

---

> >| Thomas Deiß, Nokia Research Center Street address: |
> >| P.O. Box 101823 Meesmannstraße 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. |
> >

---

> >

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

Hi,

Yes, Jens is absolutelly rigth, the components A and B are independent. But, what do you mean under error prone? Once you have two different queues, the bahaviour does not depend on their names. You would get absolutelly the same behavoiur if you defined two ports: one message and one procedure for both components.

And again, NOT THE GETCALL ALTERNATIVE WILL BE CHOSEN IN ANY OCCASION. It depends on the actual test tool implementation (is it able to separate in time the sequence of the message and the call or not). Your example simply may produce a non-reproducable (on different test tools) test behaviour, do you have a mixed port or two separate ports with different names.

Best Regards, György

============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
intranet: conformancelab.ericsson.se
personal: www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Thomas Deiß [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Thursday, March 28, 2002 11:20 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: FW: Mixed ports
>
>
>Hello Jens,
>
>thanks for the explanations you have given and for confirming
>that my understanding was correct. Nevertheless, I think it is
>error prone from a user point of view to have mixed ports as a
>short hand notation of two ports.
>
>Best regards
>
>Thomas
>
>>

---

Original Message

---

>> From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>> Sent: Mittwoch, 27. März 2002 11:30
>> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Subject: Re: FW: Mixed ports
>>
>>
>> Hi Gyorgy, Thomas and others,
>>
>> two ports with the same name really means two ports with the
>> same name.
>> The distinction between the two ports is made on the
>receiving side by
>> the receiving operations: RECEIVE, TRIGGER, GETCALL,
>> GETREPLY, CATCH and
>> CHECK (with the exception of CHECK ANY, see below), and on
>the sending
>> side by the sending operations: SEND, CALL, REPLY and RAISE.
>>
>> The port operations START, STOP and CLEAR will manipulate both ports
>> at the same time and the CHECK ANY operation (e.g.,
>Myport.CHECK) will
>> check both ports for any message, call, reply or exception.
>>
>> The decision that a mixed port is represented by one
>message-based and
>> one procedure-based port was made at one of the first
>editing meetings
>> of TTCN-3. The original proposal was to allow message-based and
>> procedure-base ports only, but no mixed ports. This leads to some
>> controversal discussions with 'SDL people', because the connection of
>> TTCN-3 with SDL systems would be a little bit tricky. As a
>compromise,
>> it was decided to introduce mixed ports as shorthand for two
>ports and
>> to distinguish between the message-based and the procedure-based port
>> on the operation level.
>>
>> (Don't blame me for my wording, it is only a very short
>> explanation for
>> the current mixed port-definition in the standard. There were
>> some other reasons related to blocking an non-blocking communication,
>> but I don't remember all these reasons.)
>>
>> Best regards
>> Jens Grabowski
>>
>>
>> "Gyorgy Rethy (ETH)" schrieb:
>> >
>> > These wicked buttons... My mail went unfinished. Sorry for
>> that. So, I try to finish it this time.
>> >
>> > Hi Thomas and others,
>> >
>> > I think no definite answer can be given for the specific
>> question. I think what shall be clarified:
>> > 1) Is the two-port-with-the-same-name approach really means
>> two virtual ports with separate queues?
>> > I think yes, there should be separate queues.
>> > 2) If 1) is true, the answer is independent if we have a
>> mixed port or two separate ports with different names.
>> Theoretically the branch receiving m should be chosen. In
>> practical terms there may be a racing condition and the tool
>> may not be able to decide which event was the first - both
>> may be registered by the same snapshot. In this case either
>> alternatives may be chosen (the receive branch will be chosen
>> if the tool is able to say, this was the first).
>> >
>> > Best Regards, György
>> > ============================================
>> > dr. György RÉTHY
>> > Ericsson Communications Systems Hungary Lim.
>> > Conformance Center
>> > tel.: +36 1 437-7006; fax: +36 1 437-7767
>> > mobile: +36 30 297-7862
>> > e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> > intranet: conformancelab.ericsson.se
>> > personal: www.r.eth.ericsson.se/~ethgry
>> > ============================================
>> >
>> > >

---

Original Message

---

>> > >From: Thomas Deiß [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>> > >Sent: Wednesday, March 27, 2002 8:17 AM
>> > >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> > >Subject: Mixed ports
>> > >
>> > >
>> > >Good morning,
>> > >
>> > >The TTCN-3 Core Language standard makes a statement how mixed
>> > >ports shall be understood: "A mixed port in TTCN-3 is defined
>> > >as a shorthand notation for two ports, i.e. a message-based
>> > >port and a procedure-based port with the same name. At
>> > >run-time the distinction between the two ports is made by the
>> > >communication operations." This statement has a strange
>> > >consequence when receiving messages or accepting procecure
>> > >calls from a mixed port.
>> > >
>> > >Could somebody please comment whether I understood the
>> > >following behavior correctly. Thanks.
>> > >
>> > >Assume, there are two components A and B which both have a
>> > >mixed port P and that the ports P of A and of B are connected.
>> > >Assume also that A sends first a message m on this port and
>> > >then calls a procedure p on this port:
>> > >
>> > >A:
>> > >P.send(m);
>> > >P.call(p) { ... };
>> > >
>> > >On the sending side there is a clear temporal order between
>> > >sending m and calling p.
>> > >
>> > >Assume now that component B executes an alt statement in which
>> > >the first alternative matches on p and the second one on m.
>> > >And assume there is sufficient time to insert both m and p in
>> > >the queue of the port p at B.
>> > >
>> > >B:
>> > >alt {
>> > > [] P.getcall(p) { ... };
>> > > [] P.receive(m) { ... }
>> > >}
>> > >
>> > >Because the message m has been send before the procedure p one
>> > >might assume that the first alternative to match is the one
>> > >guarded by the receive statement. But as explained in the
>> > >standard two ports - both called P - are actually used in this
>> > >alt statement. One message based, containing m, one procedure
>> > >based, containing p. Consequently, the first alternative
>> > >guarded by the getcall statement will be executed.
>> > >
>> > >Again, my question is whether this understanding is correct.
>> > >
>> > >Best regards
>> > >
>> > >Thomas
>> > >
>> > >
>> > >
>> >
>>

---

>> > >| Thomas Deiß, Nokia Research Center Street address:
> |
>> > >| P.O. Box 101823 Meesmannstraße
>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.
> |
>> >
>>

---

>> > >
>>
>> --
>>
>>
>======================================================================
>> Dr. Jens Grabowski
>> Institute for Telematics phone: +49 451 500 3723
>> University of Luebeck fax: +49 451 500 3722
>> Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
>> (Germany) WWW:
www.itm.mu-luebeck.de
> ======================================================================
>

Hello György

Let me try to explain what I mean with error prone. And let me state that this is my personal opionon. Other persons might have a different view on this.

>

---

Original Message

---

> From: ext Gyorgy Rethy (ETH) [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Donnerstag, 28. März 2002 14:31
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: FW: Mixed ports
>
>
> Hi,
>
> Yes, Jens is absolutelly rigth, the components A and B are
> independent. But, what do you mean under error prone? Once
> you have two different queues, the bahaviour does not depend
> on their names. You would get absolutelly the same behavoiur
> if you defined two ports: one message and one procedure for
> both components.

Here it is perfectly clear that there is no order between elements in the one or the other queue.

>
> And again, NOT THE GETCALL ALTERNATIVE WILL BE CHOSEN IN ANY
> OCCASION. It depends on the actual test tool implementation
> (is it able to separate in time the sequence of the message
> and the call or not). Your example simply may produce a
> non-reproducable (on different test tools) test behaviour, do
> you have a mixed port or two separate ports with different names.

After this discussion we all understand that there is no order among elements in the queues for messages and procedure call, even the ports have the same name.

I consider mixed ports as short hand notation to be error prone because it is not obvious that actually two ports are involved. Therefore it is quiet easy to define behavior which works fine, until it is put in a different context, or executed under a different load of the host, or executed by different tools. It is simply non-reproducable, as you stated correctly.

Best regards

Thomas


>
> Best Regards, György
>
> ============================================
> dr. György RÉTHY
> Ericsson Communications Systems Hungary Lim.
> Conformance Center
> tel.: +36 1 437-7006; fax: +36 1 437-7767
> mobile: +36 30 297-7862
> e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> intranet: conformancelab.ericsson.se
> personal: www.r.eth.ericsson.se/~ethgry
> ============================================
>
>
> >

---

Original Message

---

> >From: Thomas Deiß [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> >Sent: Thursday, March 28, 2002 11:20 AM
> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >Subject: Re: FW: Mixed ports
> >
> >
> >Hello Jens,
> >
> >thanks for the explanations you have given and for confirming
> >that my understanding was correct. Nevertheless, I think it is
> >error prone from a user point of view to have mixed ports as a
> >short hand notation of two ports.
> >
> >Best regards
> >
> >Thomas
> >
> >>

---

Original Message

---

> >> From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> >> Sent: Mittwoch, 27. März 2002 11:30
> >> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> Subject: Re: FW: Mixed ports
> >>
> >>
> >> Hi Gyorgy, Thomas and others,
> >>
> >> two ports with the same name really means two ports with the
> >> same name.
> >> The distinction between the two ports is made on the
> >receiving side by
> >> the receiving operations: RECEIVE, TRIGGER, GETCALL,
> >> GETREPLY, CATCH and
> >> CHECK (with the exception of CHECK ANY, see below), and on
> >the sending
> >> side by the sending operations: SEND, CALL, REPLY and RAISE.
> >>
> >> The port operations START, STOP and CLEAR will manipulate
> both ports
> >> at the same time and the CHECK ANY operation (e.g.,
> >Myport.CHECK) will
> >> check both ports for any message, call, reply or exception.
> >>
> >> The decision that a mixed port is represented by one
> >message-based and
> >> one procedure-based port was made at one of the first
> >editing meetings
> >> of TTCN-3. The original proposal was to allow message-based and
> >> procedure-base ports only, but no mixed ports. This leads to some
> >> controversal discussions with 'SDL people', because the
> connection of
> >> TTCN-3 with SDL systems would be a little bit tricky. As a
> >compromise,
> >> it was decided to introduce mixed ports as shorthand for two
> >ports and
> >> to distinguish between the message-based and the
> procedure-based port
> >> on the operation level.
> >>
> >> (Don't blame me for my wording, it is only a very short
> >> explanation for
> >> the current mixed port-definition in the standard. There were
> >> some other reasons related to blocking an non-blocking
> communication,
> >> but I don't remember all these reasons.)
> >>
> >> Best regards
> >> Jens Grabowski
> >>
> >>
> >> "Gyorgy Rethy (ETH)" schrieb:
> >> >
> >> > These wicked buttons... My mail went unfinished. Sorry for
> >> that. So, I try to finish it this time.
> >> >
> >> > Hi Thomas and others,
> >> >
> >> > I think no definite answer can be given for the specific
> >> question. I think what shall be clarified:
> >> > 1) Is the two-port-with-the-same-name approach really means
> >> two virtual ports with separate queues?
> >> > I think yes, there should be separate queues.
> >> > 2) If 1) is true, the answer is independent if we have a
> >> mixed port or two separate ports with different names.
> >> Theoretically the branch receiving m should be chosen. In
> >> practical terms there may be a racing condition and the tool
> >> may not be able to decide which event was the first - both
> >> may be registered by the same snapshot. In this case either
> >> alternatives may be chosen (the receive branch will be chosen
> >> if the tool is able to say, this was the first).
> >> >
> >> > Best Regards, György
> >> > ============================================
> >> > dr. György RÉTHY
> >> > Ericsson Communications Systems Hungary Lim.
> >> > Conformance Center
> >> > tel.: +36 1 437-7006; fax: +36 1 437-7767
> >> > mobile: +36 30 297-7862
> >> > e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> > intranet: conformancelab.ericsson.se
> >> > personal: www.r.eth.ericsson.se/~ethgry
> >> > ============================================
> >> >
> >> > >

---

Original Message

---

> >> > >From: Thomas Deiß [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> >> > >Sent: Wednesday, March 27, 2002 8:17 AM
> >> > >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> > >Subject: Mixed ports
> >> > >
> >> > >
> >> > >Good morning,
> >> > >
> >> > >The TTCN-3 Core Language standard makes a statement how mixed
> >> > >ports shall be understood: "A mixed port in TTCN-3 is defined
> >> > >as a shorthand notation for two ports, i.e. a message-based
> >> > >port and a procedure-based port with the same name. At
> >> > >run-time the distinction between the two ports is made by the
> >> > >communication operations." This statement has a strange
> >> > >consequence when receiving messages or accepting procecure
> >> > >calls from a mixed port.
> >> > >
> >> > >Could somebody please comment whether I understood the
> >> > >following behavior correctly. Thanks.
> >> > >
> >> > >Assume, there are two components A and B which both have a
> >> > >mixed port P and that the ports P of A and of B are connected.
> >> > >Assume also that A sends first a message m on this port and
> >> > >then calls a procedure p on this port:
> >> > >
> >> > >A:
> >> > >P.send(m);
> >> > >P.call(p) { ... };
> >> > >
> >> > >On the sending side there is a clear temporal order between
> >> > >sending m and calling p.
> >> > >
> >> > >Assume now that component B executes an alt statement in which
> >> > >the first alternative matches on p and the second one on m.
> >> > >And assume there is sufficient time to insert both m and p in
> >> > >the queue of the port p at B.
> >> > >
> >> > >B:
> >> > >alt {
> >> > > [] P.getcall(p) { ... };
> >> > > [] P.receive(m) { ... }
> >> > >}
> >> > >
> >> > >Because the message m has been send before the procedure p one
> >> > >might assume that the first alternative to match is the one
> >> > >guarded by the receive statement. But as explained in the
> >> > >standard two ports - both called P - are actually used in this
> >> > >alt statement. One message based, containing m, one procedure
> >> > >based, containing p. Consequently, the first alternative
> >> > >guarded by the getcall statement will be executed.
> >> > >
> >> > >Again, my question is whether this understanding is correct.
> >> > >
> >> > >Best regards
> >> > >
> >> > >Thomas
> >> > >
> >> > >
> >> > >
> >> >
> >>

---

> >> > >| Thomas Deiß, Nokia Research Center Street address:
> > |
> >> > >| P.O. Box 101823 Meesmannstraße
> >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.
> > |
> >> >
> >>

---

> >> > >
> >>
> >> --
> >>
> >>
> >=============================================================
> =========
> >> Dr. Jens Grabowski
> >> Institute for Telematics phone: +49 451 500 3723
> >> University of Luebeck fax: +49 451 500 3722
> >> Ratzeburger Allee 160 eMail:
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> (Germany) WWW:
> www.itm.mu-luebeck.de
> >
> ======================================================================
> >
>