Regarding the error message ""The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element. [...]":

In the new version we are working on (2021.1), we have made following changes:

1. Increased the initial limit settings so that with default chunk size (1000 for subscriptions), and with our test server, the limits are not exceeded.
2. Made it possible to configure the various parameters of BasicHttpBinding through a configuration file.

If you we willing to work with a prerelease version, I can provide it to you. If so, let me know whether you use the "Setup" installer, or just the NuGet packages, or both.

Best regards

Hello.
Some foreword:

A. Regarding the links to other forums posts you have provided in your first post: Do not rely on information from these posts (without further verifying them with us), because a) some of it is obsolete, and b) most of it applies only to OPC DA (COM-based); the internal implementation of OPC XML-DA is different, and many of the settings mentioned in these posts have no effect.

B. We have not aimed at speed or larger volumes with our OPC XML-DA support. The intent was to complement the existing OPC DA functionality, keeping the high-level API.

To the parallelism/concurrency:

There is no point in making parallel calls to a single EasyDAClient instance. The instance maintains a single connection to each target server (one, in your case), and there is a single request/response at any point in time on that connection. Consequently, all these parallel calls will get serialized on the client side.

If you truly wanted to make calls concurrently, you would have to use separate EasyDAClient instances, AND set their Isolated property (right after creation) to True. However:
- Doing so would create parallel calls/connection to the server, so one needs to consider how many the server would be able to handle.
- We generally do not recommend having too many EasyDAClient instances - they are a bit heavy on the client side too.
- Some servers might serialize the calls, so with such server there will not be any gain.
- With most real servers, the bottleneck is in their communication link to the device. And this is a physical thing, so the server *has* to serialize access to the device. Calls like Read, if made in parallel, will end up serialized with practically any real server, so parallelization would bring no gain. Yes, with calls like Browse there is better chance that it would help, because the address space is usually (but not always) loaded in server's memory already - many servers do not need any device access is needed. Calls like Subscribe are somewhere in the middle - they may or may not need serialization on the server side; it depends.

You certainly need to be prepared for the fact that effects of parallelization might differ significantly between a simulation server (or a real server in simulation mode) and the real server.

My understanding is that for Browse, you do not get any errors. So I would just measure which approach (parallel or not) works better, and use that. But it should be the real parallelization - with separate EasyDAClient-s set to Isolated. If that does not help, you might be facing a real block with OPC XML-DA, which is in the fact that the Browse request is for a single starting item only. In other words, with a hierarchical address space where each of you assets has its own "root node" and then a structure beneath it, even if you know multiple nodes you would like to browse into (such as all the assets nodes, after the first level browse), OPC XML-DA cannot browse them in one request (this is fixed in OPC UA). So either you do it one by one, or try to parallelize, but there is nothing better than that - it's not a client a problem, it's OPC XML-DA problem. Depending on the application, caching the browse results on the client side may be a solution.

With Subscribe, I do not expect the parallelization to be of real help, *plus* it only makes sense to think about after having dealt with the error ("The maximum message size quota for incoming messages (65536) has been exceeded… ).

The error indeed has to do with the underlying communication parameters/limits. And there are two possible approaches:
a) Increase the limits. Unfortunately we do not have/expose a way to do so currently. I will ask the developer who worked on this part to assess how difficult it would be to provide something in this area to help you out.

b) Chunk the Subscribe-s. You can do it yourself, but you do not have to - there is a built-in mechanism that already does it. And, for Subscribe, it is set to make chunks of maximum size of 1000 items by default. Apparently that is still too high.

Instructions on how to change the chunk size are here: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...html#OPC%20DA%20Optimizer.html

If you do not get good results by yourself with reasonable effort, but were willing to help us set up a repro, we might then be able to analyze things on our side.

Best regards

Hello,
can you please provide some additional information, before I answer your questions?

1. Although this appears just once, mentioned "by the way" in your post, please confirm that we are talking strictly about about OPC XML-DA only, and not OPC Data Access (COM-based).

2. [we have] "100 assets": Please confirm that you are, in f=effect, communicating to just one target OPC server. Or are you connecting to multiple servers?

3. What is the vendor/model of the OPC server you are connecting to? Does it have a public demo available, or documentation/info pages?

4. What is the nature of network between your client, and the server? Is it fast or slow?

5. Do you have any way to assess whether your results are related to what the client side is doing? I mean, do you have some other client app that is doing similar things - from the same computer to the same server - and if so, what results are you seeing with it?

Thank you