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

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

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

(0010011)
Gyorgy Rethy (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
26-05-2011 12:13

added a proposal, please review

(0010104)
Gyorgy Rethy (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
30-11-2011 10:27

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

(0010501)
Gyorgy Rethy (reporter)
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 (reporter)
02-12-2011 10:47

okay

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

reopen for reassignment

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

closed again

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

Implemented as proposed in v2 with editorial adjustments

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 (reporter) 24-05-2011 12:40	Check the current situation in Parts 1 and 5 and with tool vendors , if needed.

(0010011) Gyorgy Rethy (reporter) 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 (reporter) 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 (reporter) 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 (reporter) 26-05-2011 12:13	added a proposal, please review

(0010104) Gyorgy Rethy (reporter) 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 (reporter) 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 (reporter) 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 (reporter) 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 (reporter) 30-11-2011 10:27	I have too much CRs assigned, Jens, pls. review.

(0010501) Gyorgy Rethy (reporter) 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 (reporter) 02-12-2011 10:47	okay

(0010507) Jacob Wieland - Spirent (reporter) 02-12-2011 10:50	reopen for reassignment

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

(0010811) Ina Schieferdecker (reporter) 11-07-2012 10:27	Implemented as proposed in v2 with editorial adjustments

Relationships

ETSI's Bug Tracker