Message sending: the max chunks and total message size of peer are restricted by self limits
Description
The maximum number of chunks and total message size is limited by the maximum defined in S2OPC configuration SOPC_MAX_NB_CHUNKS
and SOPC_MAX_MESSAGE_LENGTH
. This is the case for reception but also for sending messages.
Since the peer Client (resp. Server) is allowed to define its own values in the HELLO (resp. ACK) message and those are not negotiated in this phase but are only declared. S2OPC should comply with the values provided by peer and not the one it uses in reception.
Analysis
Regarding the specification part 4 and part 6, only the following error codes are possible to indicate a "too large" message:
-
Bad_RequestTooLarge: The request message size exceeds limits set by the server.
(v1.03, part 4, table 172) -
Bad_ResponseTooLarge: The response message size exceeds limits set by the client.
(v1.03, part 4, table 172) -
TcpMessageTooLarge: The size of the Message specified in the header is too large. The Server returns this error if the Message size exceeds its maximum buffer size or the receive buffer size negotiated during the Hello/Acknowledge exchange.
(v1.03, part 6, table 38)
In cases of 1. and 2., it is only stated that the limit of the peer is the only reason to raise those status codes. It is not meant to be used for internal limits. Those status codes are indicated to be used both in part 4 for the limits the CreateSession
service (maxResponseMessageSize
and maxRequestMessageSize
parameters) and in part 6 for the limits of the TCPUA protocol during HEL/ACK (MaxMessageSize
and MaxChunkCount
parameters).
In case of 3., it concerns only the limits in reception of a single chunk. The size of the total message is not concerned.
As a consequence, when sending a message the constraints are only set by the peer on the total message size or the number of chunks. Strictly applying the specification makes possible not to have any limit (when 0
value is used for all parameters MaxMessageSize
, MaxChunkCount
, maxResponseMessageSize
and maxRequestMessageSize
).
There is only one other status code which might be used to still keep a possible limitation, but it is meant to be used only during reception:
Bad_EncodingLimitsExceeded: The message encoding/decoding limits imposed by the Communication Stack have been exceeded.
An issue has been opened in OPC UA foundation mantis tracker to use Bad_EncodingLimitsExceeded
in the case of self limitation when sending message: https://apps.opcfoundation.org/mantis/view.php?id=5524
Implementation
Define distinct constants for sending and for receiving. Retrieve information when encoding message and not when sending to send a service fault at service level and not an abort/error message at secure channel level. Make those parameters configurable by application.