Connections may be initiated by the Client or by the Server when they create a TransportConnection and establish a communication with their peer. The connection is initiated by using an EndpointUrl that specifies a network address where a peer listens for new connections. The EndpointUrl specifies a network address that is accessible to the initiator. If the listener is behind a NAT firewall, the EndpointUrl specifies an address outside the firewall. If the EndpointUrl specifies a domain name then the initiator requires access to a domain name resolution service (e.g., the DNS protocol) that maps the domain name onto a usable network address. OPC 10000-7 defines Profiles for different name resolution protocols that Clients and Servers may support.

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 Server application does not do any processing while the SecureChannel is negotiated; however, the Server application shall 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 sequence of Messages when establishing a Client initiated OPC UA Connection Protocol connection is shown in Figure 18.

Figure 18 – 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 19.

Figure 19 – Server initiated OPC UA Connection Protocol connection

For Server-initiated connections, 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 EndpointUrl which may be use to establish a connection.wh. 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. In this case, the administrator shall also provide an ApplicationUri which can be used to find the Client in the GDS.

Servers shall maintain at least one open socket without an active Session with each Client it is configured to connect to. Servers may delay re-connecting if the Client reports an error. Table 73 describes the process in full and how the Server is expected to react to different actions by the Client.

Table 73 – Client and Server Handshake during Reverse Connect

Action	Notes
Open Connection	Server creates a socket to a URL specified in its configuration. Client shall close the socket after short delay if no ReverseHello Message received. Server shall create a new socket because it cannot know if it was a network issue or due to action by the Client.
Reverse Hello	Server sends ReverseHello with its ApplicationUri. Client may check the ApplicationUri. If it is not acceptable it shall close the socket. Client shall send an Error Message with the code Bad_ServerTooBusy if it does not have enough resources to keep the socket open. Client may save socket for use in the future (the sequence may pause here). If the Server receives an Error Message it shall close the socket, log the error and reconnects after a delay specified in its configuration. If the socket is closed without an Error Message, the Server shall create a new socket with or without a delay and sends a new ReverseHello Message.
HelloAcknowledgeOpen Secure Channel RequestOpen Secure Channel Response	Client establishes a SecureChannel and verifies that it trusts the Server. Client may save the SecureChannel for use in the future (the sequence may pause here). Client may use SecureChannel for Discovery or Session-less Service invocations. Once a SecureChannel is established, the Server shall create a new socket if there is not already one without an active SecureChannel. If the SecureChannel is closed, the Server shall create a new socket if there is not already one without an active SecureChannel.
Create Session	Client establishes a Session.