[NODE-OPCUA-E11] message size 16385 exceeds the negotiated message size 16384 nb chunks 1. about node-opcua HOT 9 CLOSED

I should be able to investigate without .... stay tuned

from node-opcua.

Please forward this request to nodered-contrib-opcua forum, if you need a community answer.

Alternatively, we encourage you to use @opcua/for-node-red , a industrial-grade OPC UA node for node-red developed and supported by the NodeOPCUA team at Sterfive.

from node-opcua.

Why you just rename my Issue like that?
I do not have anything to do with node-red!

I am using

const opcua = require("node-opcua");

And this seems to be a bug in your node-opcua lib. The servers maxMessageSize is 16384, which is negotiated with the client.
But the client still sends one Byte more =>16385

from node-opcua.

It was mentioned the issue was similar to #1263, which relates to node-red-contrib-opcua. Hence the confusion. Sorry for this.

Please adjust this initial issue description by filling carefully the Bug reporting template , providing clear step by step instructions to reproduce, version of node-opcua involved, describing the third party OPC Server you're trying to connect to: ( manufacturer, version) etc ....

from node-opcua.

-->

Current behavior

I have an OPC UA Client created with the node-opcua library. The connection to other OPC UA servers generally works.
But with a specific device (labeling system), this connection does not work. However,
there are other OPC UA clients that can connect to this labeling system, as I have tested myself.
The connection works with the OPC UA client "UaExpert" from Unified Automation, and you can browse through the OPC UA structure of the labeling system.

This is evidence that an OPC UA client-server connection with the labeling system generally works.

Describe the bug

First, I have enabled the following for an extended debug output.

process.env.NODEOPCUADEBUG = "TRANSPORT{HELACK-CHUNK}";

Then I used this connection routine.

this.client = opcua.OPCUAClient.create({
  endpointMustExist: true, // also tried false and different transportSettings{...}
});

I received the following outputs.

´´´
10:17:38.521Z :client_tcp_transport :285 sending Hello
... protocolVersion = 0
... receiveBufferSize = 655360
... sendBufferSize = 655360
... maxMessageSize = 0
... maxChunkCount = 0
... endpointUrl = opc.tcp://172.18.4.25:48020
...
10:17:38.523Z :client_tcp_transport :263 receiving Ack
... protocolVersion = 0
... receiveBufferSize = 16384
... sendBufferSize = 16384
... maxMessageSize = 16384
... maxChunkCount = 1
...
10:17:38:524 MESSAGE BUILDER LIMITS maxMessageSize = 16384 maxChunkCount = 1 maxChunkSize = 16384 ( 16384 )
10:17:38.527Z :message_chunker :117 [NODE-OPCUA-E11] message size 16385 exceeds the negotiated message size 16384 nb chunks 1
´´´

Subsequently, no connection is established.

As I understand it, the client and server agree on the server's maxMessageSize of 16384 bytes. However, the client violates this agreement by sending a message with 16385 bytes (one byte more than agreed upon).

Step by step instruction to reproduce

Actually i followed the advice:

#1263 (comment)

Steps to reproduce the behavior:

1. Activate:

process.env.NODEOPCUADEBUG = "TRANSPORT{HELACK-CHUNK}";

2. Try to connect:

this.client = opcua.OPCUAClient.create({
  endpointMustExist: true, // also tried false and different transportSettings{...}
});

3. Analyze Debug Output

Expected behavior

In the positive case, I would expect a successful connection setup from the client to the server.

Screenshots

Gist

process.env.NODEOPCUADEBUG = "TRANSPORT{HELACK-CHUNK}";
const { OPCUAClient } = require("node-opcua");

// replace this line with the targeted server endpoint URL:
const endpointUrl = "opc.tcp://...";
(async () => {
  const client = OPCUAClient.create({});
  await client.connect(endpointUrl);
  await client.disconnect();
})();

Context

• (x) my request is related to node-opcua acting as an OPCUA CLIENT

• ( ) my request is related to node-opcua acting as an OPCUA SERVER

• ( ) I have installed node-opcua from source ( using git clone)

• (x) I have installed node-opcua as a package ( using npm install )

• ( ) I am using an application that uses node-opcua

  • ( ) node-red
  • ( ) other : please specify

• Device: __

• OS version: __

  • (x) Windows : version : _Microsoft Windows 10 Pro: 10.0.19045 Build 19045_
  • ( ) Linux : version : __
  • ( ) MacOs : version : __
  • ( ) Raspbian: version : __
  • ( ) Other : specify : __

• Description of the other OPCUA system I am trying to connect to:

  • Name: __
  • Version: __
  • Manufacturer/Software vendor: __
  • link to the manufacturer or product site: https://

• node-opcua version: :

  "version": "2.113.0",

• Node:

  node --version = v20.5.1

from node-opcua.

can you provide

description of the other OPCUA system you are trying to connect to:

Name: __
Version: __
Manufacturer/Software vendor: __
link to the manufacturer or product site: https://

This is where it gets interesting to be able to reproduce.

• also, you mentionned that you've tried different "transportSettings{...}", what are they and what are corresponding the server negociated buffer size and message size .
  Can you provide a full gist ?

from node-opcua.

The other OPCUA system I am trying to connect to:

Name: Alpha HSM (https://www.bluhmsysteme.com/etikettierung/etikettenspender/alpha-hsm.html)
Version: (have to look up later)
Manufacturer/Software vendor: https://s-q-f.com/

So you want to buy this system to reproduce the problem?

I think the Debug log of the connection process that i provided is the most important information.

from node-opcua.

fixed in [email protected]

from node-opcua.

Thanks a lot, i tested it and it works now!

from node-opcua.