ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006629 | Ext Pack: Continuous signal support (ES 202 786) | Technical | public | 07-10-2013 14:48 | 06-01-2015 16:58

Reporter | Tomas Urban |
Assigned To | Jens Grabowski |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v1.1.1 (published 2012-04) |
Target Version | v1.3.1 (published 2015-06) | Fixed in Version |  |

Summary | 0006629: Continuous signalling: unnecessary address parameter in TRI
Description | The triSetStreamValue and triGetStreamValue contain an address parameter, but this parameter cannot be set in TTCN-3 code, because unlike the send/receive commands, the value operator doesn't contain any address part. I propose to remove the parameter from both TRI functions.
Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR6629.docx (22,239) 09-10-2013 14:29 http://oldforge.etsi.org/mantis/file_download.php?file_id=2911&type=bug CR6629_v2.docx (60,321) 08-10-2014 15:25 http://oldforge.etsi.org/mantis/file_download.php?file_id=3116&type=bug

Issue History
Date Modified | Username | Field | Change
07-10-2013 14:48 | Tomas Urban | New Issue |
07-10-2013 14:48 | Tomas Urban | Clause Reference(s) | => 6.7, 6,8
07-10-2013 14:48 | Tomas Urban | Source (company - Author) | => Elvior
08-10-2013 10:45 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Ext Pack: Config & Deployment Support (ES 202 781)
08-10-2013 10:47 | Gyorgy Rethy | Assigned To | => Ina Schieferdecker
08-10-2013 10:47 | Gyorgy Rethy | Status | new => assigned
08-10-2013 10:47 | Gyorgy Rethy | Target Version | => v1.3.1 (published 2015-06)
08-10-2013 11:19 | Ina Schieferdecker | Project | Ext Pack: Config & Deployment Support (ES 202 781) => Ext Pack: Continuous signal support (ES 202 786)
09-10-2013 12:22 | Ina Schieferdecker | Note Added: 0011727 |
09-10-2013 12:26 | Ina Schieferdecker | Note Edited: 0011727 |
09-10-2013 12:49 | Tomas Urban | Note Added: 0011729 |
09-10-2013 14:08 | Ina Schieferdecker | Note Edited: 0011727 |
09-10-2013 14:23 | Ina Schieferdecker | Note Added: 0011732 |
09-10-2013 14:29 | Ina Schieferdecker | File Added: CR6629.docx |
09-10-2013 15:07 | Ina Schieferdecker | Note Added: 0011733 |
09-10-2013 15:07 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Jens Grabowski
09-10-2013 15:07 | Ina Schieferdecker | Status | assigned => confirmed
07-04-2014 10:44 | Jens Grabowski | Note Added: 0011931 |
08-04-2014 10:45 | Jens Grabowski | Assigned To | Jens Grabowski => Tomas Urban
08-04-2014 10:45 | Jens Grabowski | Status | confirmed => assigned
08-04-2014 17:10 | Gyorgy Rethy | Product Version | => v1.1.1 (published 2012-04)
10-04-2014 14:30 | Tomas Urban | Note Added: 0012010 |
08-10-2014 14:16 | Tomas Urban | Note Edited: 0012010 | bug_revision_view_page.php?bugnote_id=12010#r79
08-10-2014 15:25 | Tomas Urban | File Added: CR6629_v2.docx |
08-10-2014 15:44 | Tomas Urban | Note Added: 0012287 |
08-10-2014 15:44 | Tomas Urban | Assigned To | Tomas Urban => Jens Grabowski
08-10-2014 15:44 | Tomas Urban | Status | assigned => confirmed
06-01-2015 16:58 | Jens Grabowski | Note Added: 0012641 |
06-01-2015 16:58 | Jens Grabowski | Status | confirmed => closed
06-01-2015 16:58 | Jens Grabowski | Resolution | open => fixed

Notes

(0011727)
Ina Schieferdecker
09-10-2013 12:22 (edited on: 09-10-2013 14:08)

We suggest to do the opposite: add the optional [to/from Address] to the apply and to the value operation. Reasoning: also a stream port could be on adapter level a "multiplex interface" which requires additional addressing.

(0011729)
Tomas Urban
09-10-2013 12:49

I am afraid such an approach causes several new problems:
1. Why multicast is not allowed? And if it is allowed, it requires additional functions in the TRI.
2. Addressing would then make sense for streaming to connected ports, so components should be allowed in the to clause as well.
3. Value operation used for reading should not contain "to", because the address in this case contains the sender, not the recepient. The core language specification uses the sender clause for this purpose, but no statement using it can be present on the right hand side of an assignment which might lead to trouble finding suitable syntax (myStreamVal := p1.value -> sender myAddr doesn't look very nice).
4. It also requires update of the data stream structures, because addresses have to be stored for each sample. That means changing many parts of the existing specification.

(0011732)
Ina Schieferdecker
09-10-2013 14:23

Right, we do not add multicasting with this! The solution is just about differentiating entities within the SUT that can be reached from the very same stream port. This is just the basic addressing concept of TTCN-3. I will upload a draft in a couple of minutes.

(0011733)
Ina Schieferdecker
09-10-2013 15:07

Please check

(0011931)
Jens Grabowski
07-04-2014 10:44

Tomas will check the drafts for changes made by Ina with regard to this CR.

(0012010)
Tomas Urban
10-04-2014 14:30 (edited on: 08-10-2014 14:16)

I still don't understand how addressing should work in case of the value operation. The value operation doesn't work like the receive operation. It is non-blocking and it returns a value. The current proposal seems to ignore this fact adding matching features to it without explaining consequences of a mismatch. In addition to that, the value operation can occur on the LHS and it would therefore make sense to allow addressing in this case too.
In my opinion, if addressing is to be used, it shall be done differently, e.g. by introducing an address operation for streaming ports. This operation would have the same scope as the value operation, i.e. it could be used both on LHS and RHS. When used on the RHS, it would return the address acquired during the last sampling step (or null if the SA didn't provide any address) and when used on the LHS, if would set the address for the next sampling step.
The specification has to deal with the fact that addresses are bound to individual sampling steps (as the address might change during the progress of a test case) and there should be a way how to get and set addresses for multiple steps. Modifying the sample data structure is probably not the best approach as this would cause backwards incompatibility. One possible solution is to define the get operations by combining the address keyword with history and values keywords:
streamport.address history(StartTime, EndTime); // returns record of address and timestamp pairs
streamport.address values(StartTime, EndTime); // returns record of addresses
The apply clause can be left as specified in the current proposal, with an additional option to use a record of addresses instead of a single address in order specify addresses for each individual step. In this case, the number of addresses must be equal to the number of items in the record of samples. Using a single address instead or a list would mean using the same address for all steps.
-> The CR requires to be discussed by the STF.

(0012287)
Tomas Urban
08-10-2014 15:44

I still think the original solution for this CR is not correct because of the reasons mentioned in my previous comments. However, introducing addresses as a third element of the sample record seems like overkill for resolving this rather minor issue. It would require quite a big set of new rules and significant changes in the TTCN-3 tools.
In my opinion, stream ports are not likely to change the address of the monitored stream in the SUT after their are connected with it. And because this connection is made by the map operation, all the necessary information for locating the SUT stream can be passed by map parameters.
For that reason, I added syntactical support for this feature (and also unmap parameters) to the new proposal. These parameters are well known from the core language specification and it should not be very difficult for the vendors to implement them. The proposal also removes addresses from the TRI part of the specification.

(0012641)
Jens Grabowski
06-01-2015 16:58

Implemented according to proposal