Connections may be initiated by the Client or by the Server when they create a TransportConnection and establish a communication with their peer. If the Client creates the TransportConnection, the first Message sent shall be a Hello which specifies the buffer sizes that the Client supports. The Server shall respond with an Acknowledge Message which completes the buffer negotiation. The negotiated buffer size shall be reported to the SecureChannel layer. The negotiated SendBufferSize specifies the size of the MessageChunks to use for Messages sent over the connection.
If the Server creates the TransportConnection the first Message shall be a ReverseHello sent to the Client. If the Client accepts the connection, it sends a Hello message back to the Server which starts the buffer negotiation described for the Client initiated connection.
The Hello/Acknowledge Messages may only be sent once. If they are received again the receiver shall report an error and close the TransportConnection. Applications accepting incoming connections shall close any TransportConnection after a period of time if it does not receive a Hello or ReverseHello Message. This period of time shall be configurable and have a default value which does not exceed two minutes.
The Client sends the OpenSecureChannel request once it receives the Acknowledge back from the Server. If the Server accepts the new channel, it shall associate the TransportConnection with the SecureChannelId. The Server uses this association to determine which TransportConnection to use when it has to send a response to the Client. The Client does the same when it receives the OpenSecureChannel response.
The sequence of Messages when establishing a Client initiated OPC UA Connection Protocol connection is shown in Figure 16.
Figure 16 – Client initiated OPC UA Connection Protocol connection
The sequence of Messages when establishing a Server initiated OPC UA Connection Protocol connection is shown in Figure 17.
Figure 17 – Server initiated OPC UA Connection Protocol connection
The Server application does not do any processing while the SecureChannel is negotiated; however, the Server application shall to provide the Stack with the list of trusted Certificates. The Stack shall provide notifications to the Server application whenever it receives an OpenSecureChannel request. These notifications shall include the OpenSecureChannel or Error response returned to the Client.
The Server needs to be configured and enabled by an administrator to connect to one or more Clients. For each Client, the administrator shall provide an ApplicationUri and an EndpointUrl for the Client. If the Client EndpointUrl is not known, the administrator may provide the EndpointUrl for a GDS (see OPC 10000-12) which knows about the Client. The Server should expect that it will take some time for a Client to respond to a ReverseHello. Once a Client closes a SecureChannel or if the socket is closed without establishing a SecureChannel the Server shall create a new socket and send a new ReverseHello message. When a SecureChannel is established, the Server shall immediately create a new socket and sends a new ReverseHello to ensure the Client is able to create another SecureChannel if it is needed. Administrators may limit the number of simultaneous sockets that a Server will create.