I need to read an HHTP response (containing a JSON string) using .NET HttpClient Class in LabVIEW.
This works, but there is a nagging behaviour in the response which I’d like to eliminate. The very first response after creating the HttpClient constructor takes about 10 times more than the consecutive ones. For example, to read a simple JSON string, the first GetStringAsync will take 3.5s and the consecutive ones will take around 350ms (comparable to the time it takes to perform the same reading using LabVIEW’s HTTP Client or DataSocket Read).
There are several posts on NI’s LabVIEW community forum reporting the same issue, and there are several responses in these posts suggesting that the issue is caused by the first call searching for a proxy. I’ve tried several ways of disabling the use of proxy, some of them suggested on NI’s forums, some of them coming from various third party forums on the web. However, so far nothing works. So, either I don’t have the right combination and/or order of properties/methods needed for disabling the proxy, or this problem has nothing to do with the proxy. I also verified with IT, we don’t use a proxy server.
As I mentioned, reading the same HTTP response works perfectly fine using LabVIEW’s HTTP Client (slightly faster than .NET HttpClient) or DataSocket (about twice as fast as .NET HttpClient) and neither of these functions have the drawback of the slow first reading. Unfortunately, in this specific application, I can’t use them because neither of them supports IPv6, and the device I am reading from is IPv6 only (does not support IPv4).
Many thanks for your help.
I’m not a connectivity expert, but I believe that this might be expected behavior. First calls from .NET assemblies to a web service will always take longer due to the generation of a serialization assembly. I’ve attached a link that hopefully describes this better than I can.
The solution for LabVIEW is to build your own .NET code that includes the serialization assembly and then call it from LabVIEW.
If I’m way off the mark here, please let me know. If you could post a code snippet as well, that would help me better understand how your code is structured.
Thank you for your response.
Yes, it seems that the first call taking a bit longer is a consistent behavior, not only for .NET HTTP Client, but also for LabVIEW HTTP Client and DataSocket Read. However, the time difference between the very first and consecutive calls in case of LabVIEW HTTP Client and DataSocket Read is practically negligible, while it is prohibitive in case of the .NET HTTP Client.
It turns out that the excessive delay is due to the fact that I have two NICs in the PC. So, when both NICs are connected, the initial delay is about 3.5s, while when only one is connected (Cat6 cable unplugged from the second NIC) the delay is just below 500ms. Please see the snippet below for illustration.
Just to clarify again, the reason I’m trying to replace LabVIEW HTTP Client and DataSocket Read with .NET HTTP Client is because .NET supports IPv6 and LabVIEW doesn’t.
So the question for the NET experts on this forum is: can you please suggest a way in .NET to define a specific NIC to be used with the subsequent HTTP commands? The assumption is that the initial delay could be avoided by pointing the HTTP calls to a particular NIC.
It is possible you can use IPEndPoint for that. http://stackoverflow.com/questions/4547032/choose-one-of-many-internet-connections-for-an-applicatio...
Thanks for the link.
The first answer in the link suggests using either TCP Client or Sockets.
The second answer suggests using HttpWebRequest.
Since I’m trying to solve this using the HTTP Client (in LabVIEW, not in Visual Studio), would you know if there is a way to point he HTTP Client to a specific NIC.