Closed JayeshThamke closed 6 years ago
This appears to be the same as #73. Investigating.
Rather than using HEAD, could you try tag 1.0.3? This could be a regression in the OPC stack introduced when switching to the official nuget. But that's just a hunch.
Thanks for reply @marcschier This appears to be the same as #73. Investigating. RE: Probably yes, however the difference is in #73 the proxy worked correctly on one machine and issues running with separate machines.
Yes, and it seems that while the outcome was the same, #73 seemed to be a DNS issue.
@marcschier could you try tag 1.0.3? RE: I am using tag 1.0.3
Good, then we can exclude the upgrade to 0.4.1 of the stack assemblies having caused a regression. Seeing that there is quite some data exchanged with the .net Core server it could also be a certificate issue. The server will close the client socket if it does not trust the client. For the netcoreconsoleserver to trust the test client app, you need to copy the generated public cert from the client "own cert" to the trustedcerts of the server. If you have not done that, please try this. Btw., the Reference Server that uses WPF has a handy dialog that allows you to trust the client regardless of the presented cert, so you could use that server application as well if you are not familiar with the PKI folder structures used by the OPC stack.
And item 2 should not cause issues, it is due to Relay assembly referencing an old assembly and the proxy needing a newer one. There must be a way to suppress or redirect this, but I have not found it with .net Core tooling. Maybe you know a way, I would love to get rid of the warning ...
Thanks for reply
Update: I have just tried this on master (using the OPC-UA sample from the new .net API and samples repo) against the .net Standard master branch WPF based server sample and it worked fine.
hello @marcschier
I have tried to connect test client (from azure-iot-edge-proxy module) with netcoreconsoleserver as well as with WPF Reference server app. (both time without proxy) I did not find any rejected client certificates in servers' cert>RejectedCertificates folder and client console output was
Console output: Test Client
.Net Core OPC UA Console Client
1 - Create an Application Configuration.
2 - Discover endpoints of opc.tcp://desktop-hilrmkb:51210/UA/SampleServer.
Selected endpoint uses: Basic256Sha256
3 - Create session with OPC UA server.
One or more error(s) occurred:
-> Error establishing a connection: BadNotConnected
Press any key to exit
Now I have no clue why it is throwing exception during session creation.
var session = await Session.Create(config, endpoint, true, _clientName, 60000, null, null);
Does the simple.dll test work? Run it on the same machine where the proxy runs. Supply it only the -p option to simple.dll. If there is activity, we can isolate your issue to OPC.
Also, to confirm, the OPC console client from the stack repo works for you fine?
Hi @marcschier RE 2: OPC Console client from stack repo: NetCoreConsoleServer works fine with NetCoreConsoleClient, UA SampleClient, UA QuickStart Reference Client, UaExpert from Unified Automation GmbH (attached images below)
RE 1: Running "Simple" -p
(performance):
It transacted messages to IoTHub and logged messages on proxyd console. Simple console updated the speed of the data transaction.
Quick questions> Is the bufferSize = 60000
equivalent to number of messages transmitted to IoTHub ?
Because it has filled my IoTHub messages quota. Oops!
Also do you have any idea if I can store these messages to blob storage using stream analytics job? I have already started stream job but did not store any .json file.
Hi @marcschier
record.Id
is converted to lower case during checking connection of record. IoTHubServices.cs > internal async Task
IsConnectedAsync(INameRecod, CancellationToken) following line of code: record.Id.ToLowerInvariant()
Running Proxy module (build>cmake>x64>bin>Debug>proxyd.exe) extracts the host name and installs a proxy device in IotHub e.g. DESKTOP-0456 (no case change).
As it is converted in lower case the proxy api opc ua test client application does not recognize installed proxy device in IoTHub.
This is not case when proxy module is ran with docker container, it by default generates alpha(lower case)-numeric id.
Workaround for my case is always run proxy with proxyd.exe --name "<lower-case letters>"
and then I can run tests.
b. IoTHub message counter increments for OPC UA Server - Client communication and Browse operation, How can I store send receive transactions in blob storage?
WcfChannelBase.g_CustomTransportChannel = new ProxyTransportChannelFactory
what is significance of it? is there documentation for more information ? Thanks, Jay
Re 1, see #83 - we will track this there. Re 2, expected behavior. OPC server hangs up on SessionClose message and then we notify the client side through the exception as per Socket API behavior. Re 3. Expected due to status updates being sent while device connected. See IoT hub docs on docs.microsoft.com for how to route messages to blob storage. Re 4. It's a hook mechanism to replace the tcp transport channel factory with one that uses the proxy assembly. Unfortunately doc for this can at this point only be found in the OPC reference stack code itself as this is not a Microsoft Product, but OSS.
1) I attempted to connect test client and NetCoreConsoleServer app via OPC Prroxy module on Windows 10 (VS 2017). Following the procedure: a) Started NetCoreConsoleServer app b) Started Proxy c) Started test client from VS 2017. After debugging test client I found during Endpoint Discovery process it is throwing 'ServiceResultException - BadNotConnected', it is thrown from OPC UA .NET Standard (Client dll) library side.
I then have tried to connect NetCoreConsoleServer with NetCoreConsoleClient app, their connection works fine.
Is it possible because of difference between RuntimeFramework versions?
Console output: Test Client
Console Output: Proxy
proxy_opc_client_build_warnings.txt
I got warning messages related to "MSB3277: dependent assembly version conflicts"below and I cannot run the project using
proxy_opc_client_run_error.txt
Thanks for your answers, Jayesh