Unable to resolve error: Bad_TcpMessageTooLarge max chunk count exceeded (64)

[bsalmilo]

Hi guy, apologies if this has been discussed already. I've been combing through documentation and various forums but I haven't been able to figure out what the issue is. The full error:

ERROR org.eclipse.milo.opcua.stack.client.transport.uasc.UascClientMessageHandler - Exception caught: UaException: status=Bad_TcpMessageTooLarge, message=max chunk count exceeded (64). 

This occurs when I try to call the browse function on a node, as described here - https://javadoc.io/static/org.eclipse.milo/sdk-client/0.3.3/org/eclipse/milo/opcua/sdk/client/api/services/ViewServices.html#browse-org.eclipse.milo.opcua.stack.core.types.structured.BrowseDescription-.

My research led to me this forum - https://www.eclipse.org/lists/milo-dev/msg00967.html which told me to try using MaxReferencesPerNode toggle. This meant I had to change my request to the other browse method, which returns a BrowseResponse as opposed to a BrowseResult. Which is fine. However this led me to a different issue.

stdout. UaException: status=Bad_Timeout, message=requestId=4 timed out after 60000ms.

Seems to not be able to perform the browsing in time anymore.

Not sure where to go from here as information on this seems pretty limited so any help would be fantastic. Thanks.

[kevinherron]

It would be useful if you could get a Wireshark capture and upload it here. It seems the server you’re connected to isn’t responding in time but I’d like to verify.

[bsalmilo]

You either need to increase the message size, or do something different in your request to reduce the number of references returned, which seems to be the route you've chosen.You may need to do some combination of reducing the number of nodes your browse at once (number of BrowseDescriptions in the call) and/or reducing the max references per node.

I believe that there is only one browse description in the call. Originally, I was calling the version of browse that "browses a singular node." After the update, I believe it still only browsed that singular node.

What would you advise setting the maxReferencesPerNode to?

[kevinherron]

You could just try 1000 and see if it's your issue or not. I don't like guessing what's going on here, I'd rather look at a capture.

[bsalmilo]

Seems to still get the same timeout issue. I spoke to my security team and unfortunately I don't think I'm able to provide a capture - but I don't see anything notable in there anyway. Is there anything else I can maybe provide?

[kevinherron]

No, not really. That timeout error means the server isn't responding within the default 60s timeout period the client waits for a response.

You'll just have to look closely at a capture that results in a response vs a capture that results in a timeout and try to figure out what's different.

[bsalmilo]

From what I can see when filtering for OpcUa in a correct response there are many BrowseRequest/BrowseResponses that populate, but in the failure there is only 1. Other than that, there's no indication of a timeout taking place.

[bsalmilo]

Update - I manually increased the max chunk count to 128 in the client creator and that seemed to resolve the issue. My question is - is this an appropriate solution? Are there any ramifications of doing this down the line? @kevinherron

[kevinherron]

No, it doesn't work that way. The client tells the server its limits in the opening Hello message. The server tells the client its limits in the Acknowledge message. These values aren't reported to the application layer in any way.

Servers can report the "max operations per" for each service in the address space, but even then there are corner cases where you send a request within those limits and it generates a response that is too large for one of the parties.

You need to just code your client somewhat defensively when it comes to the service calls it makes. Keep them reasonably sized, especially the ones that can blow up in size like Browse, and have some way to configure the size of the calls at runtime.

[bsalmilo]

Sorry for the ongoing discussion on this. Really appreciate all your help. I tried implementing some kind of pagination by using BrowseNext instead of browse, but still running into the same chunk issue. Do you happen to have any other suggestions beyond increasing the encoding limits?

[kevinherron]

How many BrowseDescriptions are you passing to each Browse service call? Limiting this should limit the size of the BrowseResponse. If you're only passing 1, then limiting the maxReferencesPerNode should limit the size. If this doesn't work, the server may be ignoring the parameter and there's nothing you can do except increase encoding limits. A Wireshark capture would help a lot here.

[bsalmilo]

The node that fails has only 1 reference variable node. Is this because of the historic accumulation of the previous nodes that the message becomes too large?

[kevinherron]

Previous service calls should not affect new ones, so unless you mean previous nodes within the same BrowseRequest, not sure what is happening.