BadTimeout when sending large UaByteArrays

[Felix Meßmer]

Dear Support-Team,

I face the following problem:

I want to send sensor data through OPC-UA.
Therefore, I implemented an object type that - amongst other - consists of a variable of the type UaByteArray.
The UaByteArray variable is supposed to hold the serialized sensor data (byte stream).
I am able to write byte streams of arbitrary length (up to a million bytes long) to this variable.

But when I now want to read this variable from a client, the read service waits and then sends me a BAD-Timeout Message:

Code: Select all

TimeOut for read: 60000
** Error: UaSession::read failed [ret=BadTimeout] *********
simple_opc_client: /home/fxm/Atlas/OPC-UA/sdk_64/include/uabase/uaarraytemplates.h:50: 
T& UaStackTypeArray<T, fctClear>::operator[](OpcUa_UInt32) const 
[with T = _OpcUa_DataValue, OpcUa_Void (* fctClear)(OpcUa_Void*) = ClearDataValue, OpcUa_UInt32 = unsigned int]: 
Assertion `index<m_noOfElements' failed.
[1]+  Killed                  ./bin/simple_opc_client
Aborted

I already tried to increase the Timeout by setting a higher value for the serviceSettings. But same result.

I found out that writing byte streams of a total size of less than 65535 bytes works fine and instantly.
65536 is not working anymore.
It seems to me that at one point an array size is restricted to a size that is given with a uint16_t variable.
Is there such a restriction?

How can I send large amounts of data via OPC-UA? Is there some kind of a streaming functionality?


Best regards,
Felix Meßmer

[Felix Meßmer]

I just found that indeed there are defines for OpcUa_UInt16_Max in src/uastack/platforms/linux/opcua_p_types.h and variables m_iMaxStringLength and m_iMaxArrayLength in src/uaserver/uaservercpp/coremodule/serverconfigdata.cpp and src/uaserver/uaservercpp/uamodule/uasubscriptionmanager.cpp.

Does that have a particular reason or is it possible to increase these values?

[Support Team]

Dear Felix,

All OPC UA stacks have the same default settings for the binary serializer regarding max message size, max string length, max array size or max byte array length. The limitations are security related and can be changed in the configuration.

The compiler settings you found in the stack are just used for the default settings. The settings can be changed during startup of the application. For the server SDK you can change the serializer setting through the ServerConfig interface or in the ServerConfig.xml file (XML element ‘Serializer’). In the client SDK you can change the settings through UaPlatformLayer::changeSerializerSettings(). But you must change the settings before establishing any OPC UA communication.

But changing the serializer settings requires the change on both ends (client and server). If you cannot control both applications you may run into problems if one of the applications cannot change the settings.

It would be better to implement a logic that works for all configurations. If your data in the byte array is static, the client can read parts of the byte array step by step by using the IndexRange parameter in the Read service (ReadValueId::IndexRange).

If the data is not static, you can use the upcoming file object concept in OPC UA 1.02. The update of the OPC UA specification will have a concept for file access that can be used to access files larger than two megabyte. We can provide you more information if this concept would be of interest for you.

Best Regards,
Unified Automation Support Team

[Felix Meßmer]

Hello,

thanks for the help. The length of the byte array varies with every new value. But I think the data is not going to be larger than 2 MB.

For now, I changed the Serializer settings in ServerConfig.xml and using UaPlatformLayer::changeSerializerSettings().
So far it's fine for us that it works at all. We haven't tested the performance yet.

What's behind the file object concept?

Best regards,
Felix

[Support Team]

Dear Felix,

The upcoming update of OPC UA Part 5 defines a file object type that provides a set of methods to open, read and write files similar to the ANSI C file API.

The FileType defines methods like Open, Close, Read, Write, GetPosition, SetPosition and Properties like Size, Writeable, OpenCount.

An instance of the FileType can be used to represent a single file anywhere in the OPC UA address space or a combination of Folder objects and File objects can be used to represent a file system.

The file type will be supported in the next C++ SDK release version 1.4 if the specification update is released at this point in time.

Best Regards,
Unified Automation Support Team