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 |
|
|
|
|
Check the current situation in Parts 1 and 5 and with tool vendors , if needed. |
|
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
|
|
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. |
|
|
|
|
|
added a proposal, please review |
|
|
|
|
|
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. |
|
|
|
|
|
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 |
|
|
|
|
|
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. |
|
|
|
|
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. |
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implemented as proposed in v2 with editorial adjustments |
|