BadTcpMessageTooLarge
BadMessage limits
BadTcpMessageTooLarge means a message exceeded the size or chunk-count limits negotiated in the Hello and Acknowledge exchange. Either raise MaxMessageSize and MaxChunkCount on both peers, or - usually better - split the operation into batches so individual messages stay small.
What you actually see
Small operations work fine but one specific call fails every time: a wide Read, a large Write, a browse of a big folder, or a subscription notification carrying many values.
Why it happens
- Too many operations in one service callReading or writing thousands of nodes in a single request produces a response larger than the negotiated MaxMessageSize. The limit applies to both directions, so the failure may be on the response rather than the request.
- MaxChunkCount too low for a legitimately large messageLarge messages are split into MessageChunks. If the chunk size is small and MaxChunkCount is modest, a message that is otherwise acceptable exceeds the chunk budget. Both limits have to be considered together.
- A single very large valueAn array variable with tens of thousands of elements, a large ByteString, a file transfer chunk, or a big structure encoded as an ExtensionObject can exceed the limit on its own, with no batching mistake involved.
- Notification burst from a subscriptionA large number of monitored items changing in the same publishing cycle, or a big backlog draining after a pause, produces a large NotificationMessage. MaxNotificationsPerPublish exists exactly to bound this.
- Mismatched quotas between client and serverNegotiation takes the lower of the two peers' values. A client configured generously against a conservative embedded server still ends up with the server's small limits, which surprises people who only changed the client.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Find the negotiated limitsCapture the Hello and Acknowledge on port 4840 with the Wireshark OPC UA dissector, or log them from the stack. You need the actual negotiated ReceiveBufferSize, MaxMessageSize and MaxChunkCount, not the configured ones.
- Batch the operationSplit Reads and Writes into chunks of a few hundred nodes. Use Browse with MaxReferencesPerNode and BrowseNext continuation points instead of asking for everything at once.
- Bound subscription notificationsSet MaxNotificationsPerPublish on the subscription, and reduce monitored-item queue sizes. This turns one oversized notification into several ordinary ones.
- Raise the quotas on both peers if the data genuinely is largeFor large arrays or file transfer, increase MaxMessageSize and MaxChunkCount on client and server together, then verify the negotiated values changed. Watch memory afterwards - see BadTcpNotEnoughResources.
- Use IndexRange for large arraysRead only the slice you need with IndexRange rather than the whole array. This is often the cleanest fix for a single oversized variable, and it reduces load on the server as well.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | TransportQuotas holds MaxMessageSize, MaxChunkCount, MaxBufferSize and ChannelLifetime, and they must be raised on both the client and the server configuration to take effect. |
| node-opcua | maxMessageSize and maxChunkCount are client options and server transport settings. The stack reports the negotiated values on connect, which is the number that matters. |
| open62541 (C) | Buffer and chunk limits are set on the connection config; on constrained targets these are deliberately small, so batching on the client is the realistic fix rather than raising limits. |
| asyncua (Python) | Batch with read_values and write_values over slices of your node list. For large arrays use ua.ReadValueId with an IndexRange rather than pulling the whole array. |
| UaExpert | A Data Access view with several hundred items can trip this against a small server. Split into multiple views or reduce the item count to confirm the size limit is the cause. |
| OPC Publisher | Very large published-nodes sets against one endpoint produce big requests at startup. Splitting the configuration into several smaller entries keeps individual messages inside the limits. |
What it looks like in the log
BadTcpMessageTooLarge: message size 4194304 exceeds negotiated maximum 2097152
Chunk count 96 exceeds negotiated maxChunkCount 64 for channel 5
Read of 5000 nodes failed; retrying in batches of 500Confirm the fix
Re-run the failing operation in batches and confirm each completes Good, or confirm from a capture that the newly negotiated MaxMessageSize covers the largest message you actually send.
Stop it happening again
Batch by default in collector code, set MaxNotificationsPerPublish on every subscription, and record each server's negotiated transport quotas in the site documentation so client limits are chosen deliberately.
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.