View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
000004010000-006: Mappingspublic2006-09-04 03:322008-09-16 16:40
ReporterRandy Armstrong Assigned ToRandy Armstrong  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Summary0000040: Remove Reconnection-Recovery Semantics from the UA-TCP protocol.
Description

Automatic reconnection on error handled with in the stack is a great idea in theory, however, this implies that the stack must now implement complicated algorithms for caching/resending messages while channel recovery is taking place. No matter what algorithm is used in the stack it will not likely solve all of the error recovery requirements of the application itself. As a result, the additional effort in the stack increases the complexity of the stack without really reducing the complexity of the application layer. For that reason, I propose we remove the error recovery semantics from the TCP protocol and focus on providing accurate information to the application layer which would have to reconnect by establishing a new secure channel and calling ActivateSession again.

This changes Part 6 in two ways:

1) The lifetime will be removed from the UA-TCP headers
2) The requirement for a virtual UA-TCP connection id would be removed (i.e. only the secure channel would need a unique identifier).

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

user2

2006-10-03 18:58

  ~0000010

Last edited: 2006-10-03 19:02

This was discussed at the Portland UA Meeting. Here are the relevant conclusions (from the minutes):

TCP Connection Handling in Client

  • No connect for TCP
  • Automatic TCP connect at Channel::Open
  • Automatic TCP connect at each Service call if the connection was broken
  • Return of an TCP error if connect failed
  • Return of an SecureChannel error if the channel timed out
  • No message buffering. If the connection is broken, all outstanding requests will be returned with an error. New requests will return an error if connect does not work.
  • Server must not repeat sending responses since the client will return requests with error if connection is broken.

Based on the above is there still an issue with Part 6? Randy?

user2

2006-10-03 19:04

  ~0000011

Reminder sent to: Randy Armstrong

Randy,

Please review the conclusions (in the note attached to this bug) and determine if the issue should be closed.

user2

2006-10-24 17:06

  ~0000013

Discussed in today's telecon:

Randy to make sure the text in Part 6 reflects the expected behaivor by clients.

Randy Armstrong

2007-07-05 08:21

administrator   ~0000296

Removed from Version 0.95

Randy Armstrong

2007-10-02 22:06

administrator   ~0000362

The new revision of the protocol added this requirement back in but ties it to the SecureChannelId rather than creating a seperate identifier for the TCP connection.

Randy Armstrong

2007-11-02 23:55

administrator   ~0000456

Fixed in OPC UA Part 6 - Mappings DRAFT 1.00 Specification.doc

The reconnection semantics have been left in but the TCP connection has been merged with the secure channel so there no longer any TCP connetion id.

Issue History

Date Modified Username Field Change
2006-09-04 03:32 Randy Armstrong New Issue
2006-10-03 18:58 user2 Note Added: 0000010
2006-10-03 19:02 user2 Note Edited: 0000010
2006-10-03 19:04 user2 Note Added: 0000011
2006-10-24 17:06 user2 Note Added: 0000013
2006-10-24 17:07 user2 Status new => assigned
2006-10-24 17:07 user2 Assigned To => Randy Armstrong
2007-07-05 08:21 Randy Armstrong Status assigned => resolved
2007-07-05 08:21 Randy Armstrong Resolution open => fixed
2007-07-05 08:21 Randy Armstrong Note Added: 0000296
2007-10-02 22:05 Randy Armstrong Status resolved => assigned
2007-10-02 22:06 Randy Armstrong Status assigned => resolved
2007-10-02 22:06 Randy Armstrong Note Added: 0000362
2007-11-02 23:43 Randy Armstrong Status resolved => assigned
2007-11-02 23:55 Randy Armstrong Status assigned => resolved
2007-11-02 23:55 Randy Armstrong Note Added: 0000456
2008-09-16 16:40 user2 Status resolved => closed