I am trying to provide a UI to allow users to configure and connect to ThingWorx via a component that uses the .NET Edge SDK. However, I have encountered a number of issues with the .NET Edge SDK (version 220.127.116.119), and some seem to suggest there is static state in the API.
I attached a test application which is based on the SteamSensor sample included with the SDK. In order to let the user change the ThingWorx connection settings, and reconnect, I am creating a new instance of a SteamSensorClient with the new configuration whenever they 'Connect'. However, some static state in the SDK seems to affect behavior across these instances.
Regarding #4, I found the BaseClient.stopConnectionAttempt(), but after trying it, it does not seem to actually stops the connection attempt. It returns, but the start() call remains blocked.
Regarding #2 & #3, I am finding that a bad hostname seems to fail relatively fast, and does not put the API into a bad state. However, other issues in the URI like the port or the path will take > 1min to fail and causes the problem I described. Also, I am finding that the protocol portion of the URI seems to be ignored; I can connect using 'foo://localhost:8443/Thingworx/WS'.
Further look into #3, it seems that the 'ReconnectInterval' setting (default 60) is probably the cause of the ~1 min to fail.
Message was edited by: Ting Zuge
#1: The expected behavior of the ConnectedThingClient class (which your SteamSensorClient class extends in your example application) is to instantiate only one server connection to the main Thingworx server at a time, as it uses a twApi singleton from the C SDK (as the .NET SDK is really a wrapper for the C SDK, just like the EMS and iOS SDK also). So you can instantiate as many different ConnectedThingClients as makes sense for your project, but you can only ever connect to one instance of the Thingworx Platform at a time (as each of these instances will use the same twApi Singleton). The values of the URI and App Key can be changed, but these changes will not actually make a difference unless the ConnectedThingClient is reinitialized. When you call the Disconnect method, that doesn't actually tear down the entire connection, it just closes the socket. So the Edge Client is no longer communicating with the Thingworx Server after this. So any values entered for URI and App Key when you reconnect are basically ignored. When you Shutdown, however, everything is reset.
#2 and #3: The hostname being incorrect in the URI should fail faster than the port being incorrect as the router will just turn down the request for an invalid hostname. However, if the request reaches the server, then the C/.NET SDK will wait a full timeout before claiming an error, as you suspected about the ReconnectInterval being involved with that wait time. ConnectRetries does work in the way you are saying, where 1 refers to the first "try" in the initial connection. After it has connected, if it disconnects and tries to reconnect for any reason, it will try to reconnect the number of specified times. This is because when it initializes, it thinks it has previously disconnected (meaning that its first connection is really retry one). You are correct that Thingworx will ignore the protocol input in the URI as it forces http or https to be used depending on the encryption settings.
#2 and #4: While the SDK is trying to connect to the Thingworx Platform, no calls can be made to attempt to disconnect or shutdown the server unless some custom implementation is written. The UI you are using does not actually allow one to try to disconnect or shutdown the SDK while it is connecting (see the line containing "!String.Equals(Status, Connected)" in the Disconnect method of the EdgeTestViewModel class. Even if I modify your code to allow the UI to call "client.Shutdown()" while the Status is "Connecting", the Shutdown call is ignored by the twApi. The workaround for this is to shorten the ReconnectInterval, though this may cause issues if you are ever trying to connect to a valid but slow server.
#5: Your use case is not directly supported since, as mentioned above, the twApi is created as a singleton. You can have many many remote things connected to one Edge Client, and even multiple Edge Clients connected to a single Thingworx Platform, but you can only have one Thingworx Server connection per Edge Client at a time.
I hope that clarifies things a bit! Please let me know further questions or comments. I plan to type up several KCS articles regarding this information and inquire further about the possibility of adding a "reinitialize" functionality to our twApi singleton (so that the entire server may not need to come down in order to reset the connection), but I can't make any promises at this time.