Thanks for the input. We will try that approach.

Thanks for your input on this. As you put it, the main concern would be to ensure that we have some kind of information at a certain point in time. I don't believe it is a critical need, but I think it could be a nice feature to have.

As long as you add it to your list of considerations for the future, that would be good with me.

For now, it may be best for us to try to implement our own timer that considers the subscription call to be timed out, even though it technically has not completed or given an error yet. The main thing for this application was that it subscribes on startup but the user can still interact with the UI for other reasons. We wanted to give them some update as to the status of the subscription if it is taking too long.

Do you think that having a function that wraps GetStatus method so that we can kind of "ping" the server and see if it is available be of use?

Hi,

I am not the original poster, but I do have a question that is somewhat related to this issue. If you would like to move it to a separate thread, we can do so.

Is there any way to have influence on when the initial call to SubscribeItem times out? I am working with an application where the goal is to be as robust as possible, and one of the test cases involves removing the network connection between the client and server. Obviously, in this case, a call to SubscribeItem will fail, but it is taking a long time to do this - around a minute or so.

I know there are certain parameters for read and write timeouts. Is there something analogous to a connection timeout where we can say, after 10-15 seconds of trying to subscribe, the client will give up and throw an error? Or perhaps some method that we can call before trying to subscribe that gets the status of the server to see if it was running - maybe some wrapper around IOPCServer::GetStatus?

If it is at all possible, I would like to not have to wait for the entire subscription process to fail and return after a minute or so - or at least have some influence on when the failure is reported.

The obvious workaround is to try to read or write to a single tag and have that timeout set at a reasonable time to confirm that the connection to the server can be made, but it seems like there would be a better way to approach this.

Thank you for the advice.