Connection - Time to connection

[JonLor]

Hello,

I'm experiencing some confusing observations. I'm connecting to a local OPC UA server, running on the same machine as the client and getting a connection after approx. 6 s. When hosting the same server application on another machine on the network, the time to connection time is approx 700 ms.

I have enabled full logging to see if there are some extra activities involved in the local case, but the log files show no such activities.

Do you have any suggestions how to proceed debugging this issue? Or any explanation to the behavior?

Best regards
Jonas

[Support Team]

Hello JonLor,

we have never seen such behavior with any of our .NET SDK Samples. Can you please describe which version of the SDK you are using? Are you using the Demo-Edition? Is that an application you have written, can you reproduce with the examples prodvided by us? Are you measuring the pure "OPC UA Connect", or are you measuring the first start up of a .NET application including the Connect?

Best Regards
Support Team

[JonLor]

Hello, some more information below:

Disabling the firewall on the local machine makes the time go down to approx 700 ms.

Is this the expected behavior? Do we need to make some configuration to improve the connection times with an active firewall?

/Jonas

[JonLor]

Hello again,

SDK Version: Unified Automation UA .NET SDK Bundle 2.2.2 (BINARY Edition).

We have developed the application ourselves, but running the client against the SDK UaNETServer displays the same behavior. Also a stripped down client which basically just calls Session.Connect displays the same behavior.

We measure the time in a unit test which creates the session, calls connect and awaits the result.

Best regards
Jonas

[JonLor]

I just tried connecting the SDK sample client with the UaNETServer and the same behavior is seen here.

[Support Team]

Hi Jonas,

which Windows version are you using? What type of PC are you using, CPU sped? The Firewall should have no impact on the time needed to connect, it must be something different especially when working fast in a remote scenario where firewall is invloved too. First we need to find our which side (Client or Server) is the problem.
1) please use our ANSIC or C++ DemoServer http://www.unified-automation.com/downl ... rvers.html and test it again.
2) please check with UaExpert how fast you can connect to the Server, even withoutmeasuring you should be able to see the difference between 6s and 500ms.

As we can not observe such timing here, we assume that there must be something different regarding Windows operating system and .NET Framework version.

Best Regards
Support Team

[JonLor]

I'm using Windows 7 with a laptop (Intel i7 / 2.2 Ghz).

1) Same behavior as before
2) UA Expert connects fast regardless of firewall status

A little more information about my earlier findings:
When trying the client GettingStarted_VS2010 I'm using the Connection->Simple Connect dialog.

/Jonas

[Support Team]

Hi Jonas,

Windows 7 is a released and tested platform, in all our testing procedures the connect works extremely fast (BTW much faster that the 700ms you have measured). Independent of the Firewall settings, it just works like a charm.

So we need to find the difference on your machine. The problem occurs only when using .NET Client (independent of the Server implementation). And you are using the "simple connect" mechanism of the SDK. This simplified connect is doing several calls in the background, e.g GetEndpoints and finally the CreateSession.

1) Please use the "advanced connect" from the Getting Started. Here the simplified connect is split into the individual steps. This may give us more information where the bottleneck is located.

Our assumption is that some system function is slow on your system, maybe the name resolution is working slow e.g when you Laptop is in an Domain.
2) Please use the IPv4 looppback or "localhost" instead of you hostname (don't forget to set the UseDNSnameAndPortFromDiscoveryUrl)

Best Regards
Support Team

[JonLor]

Hello,

Regarding the 700 ms, this is the time for executing a unit test performing the connect operation. So, a little more work is performed apart from the connect, for instance, creating the Session, validating license and so on.

OK, one step closer:

1) Advanced connect gave the same result, both get endpoints and the connect operations was slow. Even with localhost specified as address. UseDNSnameAndPortFromDiscoveryUrl was not available in this dialog for me.

However, when running the simple connect again and using localhost together with UseDNSnameAndPortFromDiscoveryUrl the connect was blazing fast.

/Jonas

[Support Team]

Hi Jonas,

overall it seems to be some issue in the IP-to-name resolution of your system, which, in conjunction with firewall, is creating some delays. As this does not happen on our machines, we need to investigate what is the difference on your laptop. Have you reproduced the problem on any other Win7 machine?

1) are you in a domain and using a domain login on your laptop, or is that local?
2) is there a proper DNS server in your network that knows your laptop and can resolve the name?
3) how many network cards are connected in parallel, wlan and lan? Are they in different subnet?

Please switch on the client-side trace (app.config, use full "data" level) and do the testing again. From the timestamp in that trace we should be able to identify the calls that get delayed. Ideally you should trace the server-side as well.

Best Regards
Support Team

[JonLor]

Hello,

The issue is possible to reproduce on other machines at our site.

1) On a domain, with domain login
2) Yes, we have a DNS on our network, to know more about its capabilities I would have to inquire at the IT department (let me know if you need this)
3) I have a lan and wlan card. They are on the same subnet, however, they are not active at the same time on my machine.

I have attached the logs you requested, let me know if you want logs when the firewall is off as well.

Best regards
Jonas

[Support Team]

Hi Jonas,

the trace shows pretty clear that the name resolution takes at least 3 seconds on you local machine. The reason for that can not be seen, because this is outside the SDK and outside any OPC UA function, it is a Windows .NET function. Hence we can only guess, it is most likely unusual configuration of your DNS server (typically there are more than one) and the search order of these DNS. It should search locally first and externally on the second try. So it seems to be a problem with your network/domain configuration.
1) Please check your DNS configuration and the settings in Windows.
2) Have you ever tried without being in the domain?

Alternatively, and that is the reason why we built in this feature, you can connect "directly":
When you don't let the DNS resolve the name (e.g. when you connect the URL having IPv4 address directly) the connect runs very fast.

Note: By default the connect operates in two steps i) discover the server's endpoints by calling "GetEndpoints" ii) use the URL returned by the server and connect. Typically the Server will return its hostname within the URL, and by this proper name resolution is required.

However, in order to "force" the simple connect method to use the given Discovery-URL instead of the returned one from the Server, you must handle/overwrite the respective event handler. This is done by "UseDNSnameAndPortFromDiscoveryUrl" . If this flag is set the, plus you use "localhost" or IP-Address within the Discovery-URL, you will work arround the slow name resolution of your network.

Best Regards
Support Team