I understand the issue. I did not have to test it, because it behaves as designed. EasyUAClient serializes operations on any single session. With Isolated = false, there is just one session for all operations with the same EndpointDescriptor, so they all get serialized. With Isolated = true, there are separated sessions.

There are internal reasons for this which I also cannot easily describe. It comes down to the fact that it was easier to implement this way. When I now think about it, it might be possible to improve on that, but it would require a medium-size effort and is not something I can do without planning and preparation, I will thus make a note and see if it would be possible to improve this in version 2018.1.

Unless the customer has too many devices, I would be concerned that much about creating a couple of sessions. But I understand it is not nice.

Regards

Hi Z.,
[...]

Can you tell me if the EasyUAClient serializes ReadRequests if there are multiple calls to the ReadMultiple method made on different instances of the EasyUACLient (assuming “Isolated” = false)?

The customer’s application has multiple threads, so it’s possible that multiple calls to ReadMultiple to happen simultaneously. The customer is using a TOP Server that has two different devices, and ran into a situation where one of the devices goes down. In that case, the timeout in TOP Server is around 9 seconds. What he’s seeing is that when one device is not responsive, the other device also becomes very slow. When we look in Wireshark (or UA Diagnostics available in TOP Server), it looks like the ReadRequests are being serialized, so we have to wait for the ReadResponse from the TOP Server for the device that’s not responding before we send out another ReadRequest for the device that does respond.

If he sets the “Isolated” property to true, this behavior goes away. Of course, there is a little more overhead now because of multiple UA connections to TOP Server – but it does seem to alleviate the behavior described above. I was mainly wondering if my analysis is correct, and if so, could you give me some detail on why it was designed this way so that I can go back to the customer and explain to him?

It’s hard for me to describe this properly in text form, so If you would like to replicate this behavior so that you can see it for yourself, I have attached a zip folder that contains his sample code he provided in Visual Studio, along with a sample TOP Server Project file (in case the attachment gets stripped off, you can also download it here). If you need the installer for TOP Server, you can grab it here (or if you have Kepware, the project should open fine in Kepware as well).

To reproduce the scenario where 1 device is in a “down” state and the other is in a “running” state, you can check the “Simulated” property of one of the devices in TOP Server:





When a device is in “Simulated mode”, TOP Server fills in all of the tags with simulated values – so the client will get a good response. Leaving the other device in non-simulated mode, TOP server will go out and try to request data from the device, which will timeout.

Thanks,
C.