Closed bearsh closed 1 year ago
one message which is huge is ua.CreateSessionResponse
...
I wonder how other stacks handle huge messages...
The protocol splits large messages into chunks that will fit in the buffer. This server has default limits of 16 MB total message size and 4K number of chunks. If exceeeded the err should be ua.BadEncodingLimitsExceeded.
I'll create a test for this. Could you share your node-opcua client?
I was able to connect node-opcua client to our test server without issue. I see the node client asks for large 640K buffers with no max message size. The server will send response specifying reduced 64K buffers and 16 MB message size. This is normal negotiation. I configured the node client to use 8192 buffers and that worked as well.
strange it's working for you. is your ua.GetEndpointsResponse{}
smaller than mine?
here what I did and some logs from the opcua-server.
simple node-red setup:
node-opua settings:
server log: comments in []
INFO[0000] log level set to 'info'
INFO[0000] Starting server 'opcua-bridge@grayhound' at 'opc.tcp://grayhound:46010'
INFO[0000] tcp server on 0.0.0.0:9294
INFO[0009] -> Hello { ver: 0, rec: 10000, snd: 10000, msg: 20000, chk: 1000, ep: opc.tcp://192.168.46.172:46010 }
INFO[0009] [286] len: 28
INFO[0009] write: 28
INFO[0009] <- Ack { ver: 0, rec: 10000, snd: 10000, msg: 20000, chk: 1000, ep: 192.168.46.142:47870 }
INFO[0009] write: 135
--- &ua.ServiceFault{...}
INFO[0009] write: 52
--- &ua.CreateSessionResponse{...}
INFO[0009] write: 10000
INFO[0009] write: 5129 [<- message size is 15129]
--- &ua.ActivateSessionResponse{...}
INFO[0009] write: 96
with a smaller message size (for some reasons, node-opcua throws another error if the max message size is equal to the receive buffer size, but that's another story... so I added 1 to the max message size), the ua.GetEndpointsResponse{}
is too big:
INFO[0000] log level set to 'info'
INFO[0000] Starting server 'opcua-bridge@grayhound' at 'opc.tcp://grayhound:46010'
INFO[0000] MsrCloud: tcp server on 0.0.0.0:9294
INFO[0008] -> Hello { ver: 0, rec: 8192, snd: 8192, msg: 8193, chk: 1000, ep: opc.tcp://192.168.46.172:46010 }
INFO[0008] write: 28
INFO[0008] <- Ack { ver: 0, rec: 8192, snd: 8192, msg: 8193, chk: 1000, ep: 192.168.46.142:46200 }
INFO[0008] write: 135
--- &ua.GetEndpointsResponse{ResponseHeader:ua.ResponseHeader{...}
INFO[0008] Error handling service request for channel id '1458130056'. The message encoding/decoding limits imposed by the stack have been exceeded. [<- returned from sendServiceResponse()]
Hi @bearsh,
The ua.GetEndpointsResponse may be a large message. The server cert is repeated for every security combination the server supports.
First, we need to have buffers that are a good size (64 KB or 65536 is good). The stack will break long messages into chunks that fit in the buffer, and then re-assemble the message on the other end.
Second you should let the MaxMessageSize and MaxChunkCount be very large (16 MB and 4096 chunks).
Good luck.
I installed Node-Red to test it, and see that the default Max Chunk Count of 1 and Max Message Size of 8192 is not a good choice. You can enter zero instead. That will let the server use it's defaults.
@awcullen thanks a lot!
The ua.GetEndpointsResponse may be a large message. The server cert is repeated for every security combination the server supports.
I see, so in the end it's not a limitation of your stack but kind of a problem of the opc-ua spec... and if the client, for whatever reason, only supports smaller message size, I can argue that the server fulfills the spec so it's a problem of the client.
for node-red, using 0 for MaxMessageSize works
Hi @awcullen
I tried to connect from node-opcua to my server based on your implementation. Node-opcua has a default message size which is AFAIK the minimum required message size for a secure channel of 8192. Unfortunately the connection did not succeed until I increased the message size to a higher value. Node-opcua could connect to a open62541 based server with a message size of 8192. So my question, is this a intended behavior? I did some debugging and found out that a message is not sent if its length exceed the max message size. so does your implementation require a bigger message size then say open62541 or is there an issue chunking the messages (if this is even possible)?