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.
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.
Server creates a socket to a URL specified in its configuration.
Client may save socket for use in the future (the sequence may pause here).
HelloAcknowledgeOpen Secure Channel RequestOpen Secure Channel Response