ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0005877 | Part 01: TTCN-3 Core Language | Clarification | public | 09-04-2011 18:04 | 11-07-2012 10:27

Reporter | Gyorgy Rethy |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | always
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.4.1 (published 2012-04) | Fixed in Version | v4.5.1 (published 2013-04) |
Clause Reference(s) | 9.1
Source (company - Author) | L.M. Ericsson

Summary | 0005877: Semantics of TSI->multiple components connection is unspecified

Description

Clause 9.1 allows a connection when one TSI interface is mapped to ports of different test components (see figure 6.h)). However the semantics of this configuration is not defined. From the test component point of view this is a one-to-one connection, therefore no to/from clauses required.
SOLUTION PROPOSAL
Add a sentence to clause 9.1 clarifying that in this configuration the TSI shall put the received messages into the port queues of all connected TCs. As in this case addressing is not possible, this seems to be the only possible way.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | es_20187301v040205m_CR_5877.doc (114,176) 27-05-2011 16:26 http://oldforge.etsi.org/mantis/file_download.php?file_id=2520&type=bug es_20187301v040205m_CR_5877_v2.doc (128,000) 29-06-2011 16:41 http://oldforge.etsi.org/mantis/file_download.php?file_id=2525&type=bug

Issue History
Date Modified | Username | Field | Change
09-04-2011 18:04 | Gyorgy Rethy | New Issue |
09-04-2011 18:04 | Gyorgy Rethy | Clause Reference(s) | => 9.1
09-04-2011 18:04 | Gyorgy Rethy | Source (company - Author) | => L.M. Ericsson
24-05-2011 12:40 | Gyorgy Rethy | Note Added: 0010010 |
24-05-2011 12:40 | Gyorgy Rethy | Status | new => assigned
24-05-2011 12:40 | Gyorgy Rethy | Assigned To | => Jacob Wieland - Spirent
24-05-2011 13:50 | Gyorgy Rethy | Note Added: 0010011 |
24-05-2011 19:06 | Gyorgy Rethy | Target Version | => Edition 4.3.2 (interim)
25-05-2011 11:09 | Jacob Wieland - Spirent | Note Added: 0010045 |
25-05-2011 11:14 | Jacob Wieland - Spirent | Note Edited: 0010045 |
26-05-2011 09:53 | Gyorgy Rethy | Note Added: 0010076 |
26-05-2011 12:13 | Jacob Wieland - Spirent | File Added: es_20187301v040205m_CR_5877.doc |
26-05-2011 12:13 | Jacob Wieland - Spirent | Note Added: 0010080 |
26-05-2011 12:13 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
27-05-2011 14:18 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
27-05-2011 14:19 | Gyorgy Rethy | Assigned To | Ina Schieferdecker => Gyorgy Rethy
27-05-2011 14:25 | Gyorgy Rethy | Note Added: 0010104 |
27-05-2011 14:25 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
27-05-2011 16:26 | Jacob Wieland - Spirent | File Deleted: es_20187301v040205m_CR_5877.doc |
27-05-2011 16:26 | Jacob Wieland - Spirent | File Added: es_20187301v040205m_CR_5877.doc |
27-05-2011 16:27 | Jacob Wieland - Spirent | Note Added: 0010107 |
27-05-2011 16:29 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
29-06-2011 16:41 | Gyorgy Rethy | File Added: es_20187301v040205m_CR_5877_v2.doc |
29-06-2011 16:43 | Gyorgy Rethy | Note Added: 0010148 |
29-06-2011 16:43 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
30-06-2011 16:39 | Jacob Wieland - Spirent | Note Added: 0010163 |
30-06-2011 16:39 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
27-09-2011 13:59 | Gyorgy Rethy | Target Version | Edition 4.3.2 (interim) => Edition 4.4.1
30-11-2011 10:27 | Gyorgy Rethy | Note Added: 0010425 |
30-11-2011 10:27 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
30-11-2011 14:16 | Gyorgy Rethy | Assigned To | Jens Grabowski => Gyorgy Rethy
02-12-2011 09:38 | Gyorgy Rethy | Note Added: 0010501 |
02-12-2011 09:39 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
02-12-2011 09:39 | Gyorgy Rethy | Note Edited: 0010501 |
02-12-2011 10:47 | Jacob Wieland - Spirent | Status | assigned => resolved
02-12-2011 10:47 | Jacob Wieland - Spirent | Resolution | open => fixed
02-12-2011 10:47 | Jacob Wieland - Spirent | Note Added: 0010506 |
02-12-2011 10:50 | Jacob Wieland - Spirent | Status | resolved => feedback
02-12-2011 10:50 | Jacob Wieland - Spirent | Resolution | fixed => reopened
02-12-2011 10:50 | Jacob Wieland - Spirent | Note Added: 0010507 |
02-12-2011 10:51 | Jacob Wieland - Spirent | Status | feedback => assigned
02-12-2011 10:51 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
02-12-2011 10:52 | Jacob Wieland - Spirent | Status | assigned => resolved
02-12-2011 10:52 | Jacob Wieland - Spirent | Resolution | reopened => fixed
02-12-2011 10:52 | Jacob Wieland - Spirent | Note Added: 0010508 |
11-07-2012 10:27 | Ina Schieferdecker | Note Added: 0010811 |
11-07-2012 10:27 | Ina Schieferdecker | Status | resolved => closed
11-07-2012 10:27 | Ina Schieferdecker | Fixed in Version | => Edition 4.5.1

Notes

(0010010)
Gyorgy Rethy
24-05-2011 12:40

Check the current situation in Parts 1 and 5 and with tool vendors , if needed.

(0010011)
Gyorgy Rethy
24-05-2011 13:50

Implications to be considered: broadcast or routing within TSI? By default we are not considering to limit the TSI to one2one mappings. - shall we allow/require specifying the type of the adaptor in TTCN-3? - if yes, should it be in the port type definition or in the map or ? - shall it be formal or informal? - etc.

(0010045)
Jacob Wieland - Spirent
25-05-2011 11:09 (edited on: 25-05-2011 11:14)

If we want to allow restricting/specifying the behavior of the adapter in TTCN-3, different approaches can be taken:
1. introduce additional port modifiers like 'realtime': broadcast, unicast.
type port P mixed broadcast { ... }
-> This means that the test adapter is supposed to call triEnqueue<X>() for all components mapped to this port for any message/reply/call/exception received on this port.
type port P mixed unicast { ... }
-> This means that the test adapter must be able to disambiguate the recipient component and shall only call triEnqueue<X>() for this component.
- Drawback: two new keywords (although it would be possible to say in the BNF that any identifier can be a port modifier with the STATIC SEMANTICS that only those having a defined meaning are accepted before the opening brackets).
2. Another formal way would be to use a new kind of attribute:
type port P mixed { ... }
with {
receive "broadcast"
}
type port P mixed { ... }
with {
receive "unicast"
}
This has additional advantages:
- the attribute could be restricted to certain 'members', i.e. types/signatures of the port definition.
type port P mixed { inout T1, T2, T3 }
with {
receive (T1) "unicast"
receive (T2) "broadcast"
}
=> for T1, the port would impose unicast-restriction, for T2 broadcast-restriction and for T3 no restriction would be imposed on the test adapter.
- also we would not have to introduce new keywords, just a new attribute kind.
The drawback of this approach is that it must be communicated to the testadapter somehow, for which types it should employ which behavior (it it is a generic one). I.e. we would need a new function with a signature like: tciGetReceiveAttribute(in TriPortId port, in TciType type, out TciReceiveKind kind).
To avoid this drawback, usage of that attribute with a list of types/signatures could be forbidden, i.e. the whole port is either broadcast or unicast or decide-it-yourself.
3. The last alternative would be to use the informal way of using extension attributes:
type port P mixed { inout T1, T2, T3 }
with {
extension (T1) "receive:unicast"
extension (T2) "receive:broadcast"
}
It has the same advantages and drawbacks of alternative 2.
Modifying the map operation in my opinion is the wrong approach as that is only associated with one port-to-port mapping and has nothing to do with multi-port-to-one-port mapping. Also, this would imply that the testadapters behaviour would need to be dynamically changeable depending on the last map-statement.

(0010076)
Gyorgy Rethy
26-05-2011 09:53

A mixure of options 2 and 3 are agreed, add the new attribute system but with defined strings "receive:unicast" and "receive:broadcast". Use the general attribute overriding rules.

(0010080)
Jacob Wieland - Spirent
26-05-2011 12:13

added a proposal, please review

(0010104)
Gyorgy Rethy
27-05-2011 14:25

Actually, when opening the file, I cannot see any tracked changes, therefore there is nothing to be reviewed (yet). Also, I can see that the file contains only clause 27 and the BNF. Semantical description shall either be given in clause 9.1 and referenced from clause 27 or vice versa. But I think clause 9.1 would be a more natural place.

(0010107)
Jacob Wieland - Spirent
27-05-2011 16:27

somehow the change bars got lost. I've added a sentence to 9.1 and added section 27.8 and the system alternative in the grammar

(0010148)
Gyorgy Rethy
29-06-2011 16:43

Technically OK. I have revised the text at some places in 27.8, to e more specific. Pls. check in es_20187301v040205m_CR_5877_v2.doc.

(0010163)
Jacob Wieland - Spirent
30-06-2011 16:39

Apart from the changes from 'component' to 'port' it's ok. However these changes are wrong as the tri-function get componentIds and not portIds, so the test adapter needs to know the right components to call these functions for, not the ports.

(0010425)
Gyorgy Rethy
30-11-2011 10:27

I have too much CRs assigned, Jens, pls. review.

(0010501)
Gyorgy Rethy
02-12-2011 09:38 (edited on: 02-12-2011 09:39)

It's OK with me.
The standard does not specify the way it is implemented, but the perception of the user. Of course, in a real system you will use a componentIds to identify the receipent, but writing this in the abstract language's spec. could mismatch the user. Different types of ports may require different unicast/broadcast behaviour: this has to be considered in adapter implementations. Thus, saying that the system attribute defines the behaviour of the component would be misleading; one port type of a component may require unicast, while the other port type of the same component broadcast.
If you agree, pls. set it to resolved and assign the CR to Ina.

(0010506)
Jacob Wieland - Spirent
02-12-2011 10:47

okay

(0010507)
Jacob Wieland - Spirent
02-12-2011 10:50

reopen for reassignment

(0010508)
Jacob Wieland - Spirent
02-12-2011 10:52

closed again

(0010811)
Ina Schieferdecker
11-07-2012 10:27

Implemented as proposed in v2 with editorial adjustments