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

ID | Project | Category | View Status | Date Submitted | Last Update
0000387 | Part 01: TTCN-3 Core Language | Editorial | public | 23-11-2006 14:27 | 12-03-2008 10:27

Reporter | Stephan Schulz |
Assigned To | developer_u |
Priority | normal | Severity | feature | Reproducibility | N/A
Status | closed | Resolution | won't fix |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v3.3.2 (published 2008-04) | Fixed in Version | v3.3.2 (published 2008-04) |
Clause Reference(s) | Clause 23.2 (in 1); clause 9 (in 4)
Source (company - Author) | Andreas Ulrich, Siemens AG

Summary | 0000387: Time-constraint send operation
Description | In order to simplify the specification of a send operation followed by a time-constraint receipt operation similar to a blocking procedure-based call operation, an extension of the current send operation is proposed.
Steps To Reproduce |

Additional Information

23.2.4 Time-constraint send operation
The send operation can be extended with a list of receive operations that are expected to occur after the message was sent to the SUT. The receive operations are guarded by an implicit timer, whose optional timeout value is set at the send operation. The syntax is similar to the call operation in procedure-based communication (see Clause 23.3.1.1). The time-constraint send operation is blocked until a matching receive message is received or the timer timed out.
EXAMPLE:
// The following expression?
p.send(ReqMsgTemplate, 0.5) { // send a request message and wait at most 0.5 sec
[] p.receive(AckMsgTemplate) { // acknowledgement message received within time
setverdict(pass);
}
[] p.receive(NackMsgTemplate) { // or negative acknowledgement received
setverdict(fail);
}
[] p.catch(timeout) { // or no response received after 0.5 sec
setverdict(inconc);
}
}
// ?is a short form of
timer t := 0.5;
p.send(ReqMsgTemplate);
t.start;
alt {
[] p.receive(AckMsgTemplate) {
t.stop; setverdict(pass);
}
[] p.receive(NackMsgTemplate) {
t.stop; setverdict(fail);
}
[] t.timeout { setverdict(inconc); }
}
The time-constraint send operation can be always resolved to a simple send operation followed by explicit timer operations and an alt expression that contains the list of possible receive operations. In particular, an activated default remains enabled when the list of alternative receipts is executed. (Note the difference to the blocking call operation with optional call body, clause 23.3.1.1).
The receive operations allowed in a time-constraint send operation shall be restricted to receive, trigger, check, and catch(timeout). It is possible to perform receive operations on ports different to the port used for the send operation. The timeout catch expression shall refer to the same port as used for the send operation though. If it is desired to receive several messages that are all guarded by a single timer, then the simple send operation without the time-constraint and appropriate alt and/or interleave and timer expressions shall be used.
If necessary, it is possible to enable/disable an alternative by means of a boolean expression placed between the '[ ]' brackets of the alternative. In order to avoid unexpected side effects, the same rules as for the Boolean guards in alt statements shall be applied (see clause 20.1.1).
A.1.6.2.4 Port operations
320. PortSendOp ::= SendOpKeyword "(" SendParameter ["," SendTimerValue] ")" [ToClause]
[PortSendBody]
/* STATIC SEMANTICS PortSendBody shall be present only if SendTimerValue is used */
xxx. SendTimerValue := TimerValue
xxx. PortSendBody := BeginChar SendBodyStatementList EndChar
xxx. SendBodyStatementList ::= {SendBodyStatement [SemiColon]}+
xxx. SendBodyStatement ::= SendBodyGuard StatementBlock
xxx. SendBodyGuard ::= AltGuardChar SendBodyOps
xxx. SendBodyOps ::= ReceiveStatement | TriggerStatement | CheckStatement | CatchTimeoutStatement
xxx. CatchTimeoutStatement ::= Port Dot PortTimeoutOp
xxx. PortTimeoutOp ::= CatchOpKeyword "(" TimeoutKeyword ")"
in part 4: Operational semantics?
9.7 Replacement of time-constraint send operations
The time-constraint send operation is a short form of a simple send operation followed by an alt expression that contains the alternative receive operations plus appropriate timer operations. The replacement shall be made at the syntactical level. The receive operations allowed in a time-constraint send operation shall be restricted to receive, trigger, check, and catch(timeout).
EXAMPLE:
// The time-constraint send operation?
p.send(ReqMsgTemplate, TimeoutValue) {
[] p.receive(AckMsgTemplate) { ? }
[] ?
[] p.catch(timeout) { ? }
}
// ?shall be replaced by
timer implicit_timer;
:
p.send(ReqMsgTemplate);
implicit_timer.start(TimeoutValue);
alt {
[] p.receive(AckMsgTemplate) { implicit_timer.stop; ? }
[] ?
[] implicit_timer.timeout { ? }
}

Tags | No tags attached.
Relationships |
Attached Files |

Issue History
Date Modified | Username | Field | Change
23-11-2006 14:27 | Stephan Schulz | New Issue |
23-11-2006 14:27 | Stephan Schulz | Clause Reference(s) | => Clause 23.2 (in 1); clause 9 (in 4)
23-11-2006 14:27 | Stephan Schulz | Source (company - Author) | => Andreas Ulrich, Siemens AG
23-11-2006 14:28 | Stephan Schulz | Note Added: 0000308 |
23-11-2006 14:28 | Stephan Schulz | Status | new => confirmed
15-06-2007 19:19 | Stephan Schulz | Status | confirmed => assigned
15-06-2007 19:19 | Stephan Schulz | Assigned To | => Ina Schieferdecker
13-10-2007 19:13 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => developer_u
15-10-2007 14:40 | Ina Schieferdecker | Note Added: 0003615 |
17-10-2007 12:12 | Ina Schieferdecker | Status | assigned => closed
17-10-2007 12:12 | Ina Schieferdecker | Note Added: 0003662 |
17-10-2007 12:12 | Ina Schieferdecker | Resolution | open => fixed
18-10-2007 13:51 | Ina Schieferdecker | Status | closed => feedback
18-10-2007 13:51 | Ina Schieferdecker | Resolution | fixed => reopened
18-10-2007 13:52 | Ina Schieferdecker | Status | feedback => closed
18-10-2007 13:52 | Ina Schieferdecker | Resolution | reopened => won't fix
18-10-2007 13:52 | Ina Schieferdecker | Target Version | => Edition 3.3.1 (not yet published)
18-10-2007 13:52 | Ina Schieferdecker | Additional Information Updated |
12-03-2008 10:27 | user10 | Fixed in Version | => Edition 3.3.2 (not yet published)
12-03-2008 10:27 | user10 | Target Version | Edition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)

Notes

(0000308)
Stephan Schulz
23-11-2006 14:28

Agreed in principle

(0003615)
Ina Schieferdecker
15-10-2007 14:40

Should be considered also for raise and reply.

(0003662)
Ina Schieferdecker
17-10-2007 12:12

A timed send, timed raise and timed reply are syntactic sugar which do not add much ... more arguments will be provided by Thomas.