Good way to test connection?

Some of our clients can't activate because they're behind a big company firewall. So, I'm currently implemented a "proxy settings" dialog for my app. I want to have a "Test connection" button that will quickly verify that the details they've entered will work.

Does anyone have a suggestion for a good API call that serves to "ping" the server to verify the connection? I don't want to it to do anything, and I don't want the DLL to block the function call for traffic reasons - that would be quite frustrating. This will only be done once a blue moon.

On a related question: I notice that the proxy server URL in the registry doesn't have "http://" in front of it, it just has <hostname>:<port>. Does the DLL require the http bit?

The only way to test a connection is to run the function you want to run and if it fails with TA_E_INET or TF_E_INET then you know the connection has failed somewhere between that running process and the activation servers. Where exactly it failed is impossible to tell in a generic way.

>> "On a related question: I notice that the proxy server URL in the registry doesn't have "http://" in front of it, it just has <hostname>:<port>. Does the DLL require the http bit?"

TurboActivate doesn't store proxy URLs in the registry. Something else is doing that. And yes, you need the leading "http://"

Hi. Thanks for the reply.

I know that TurboActivate doesn't store proxy URLs in the registry. I was referring to the "Internet Settings" key used by the primary browser (HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings). A lot of proxy dialogs offer "Use browser settings" as a source of defaults for the dialog.

It's a pity that I can't implement a stand alone test that the server is up. I wanted to avoid the proxy dialog handler having to be aware of the current state of activation.

>> "A lot of proxy dialogs offer "Use browser settings" as a source of defaults for the dialog."

Oh, ok, yes, TurboActivate tries to use default proxies if they exist. They can be in the format Internet Explorer uses. TurboActivate will convert them to the proper format that TA needs.

>> "I wanted to avoid the proxy dialog handler having to be aware of the current state of activation."

I'm not quite sure what that means. Even if we had a "ping" function, and even if it succeeds, it doesn't mean that whatever activation function you call will succeed as well.

I'm not quite sure what problem you're trying to solve.

I am trying to allow the client to configure proxy settings and prove that they are working before I call another function that might fail for other reasons. If I know that comms are working then that eliminates that failure mode from consideration.

Try this then. Does calling "SetCustomProxy" reset the background counter you have that tries to manage traffic? If I call SetCustomProxy and then call some function that uses comms, will it always do the comms?

SetCustomProxy() just sets the proxy. It doesn't do anything else.

Are you asking about the 5-hour delay that IsGenuineEx() has if it fails to connect to the activation servers? If so, then the way to recheck immediately is to prompt the user, and only after the user has clicked a "Retry now" button call the IsGenuine() function. That function will retry immediately.

Does that make sense?

Yes, it makes sense.

Are you saying that IsGenuineEx() is the only function that tries to manage traffic to the servers? I somehow got the impression that most functions did (if they can fail with an INET error). Except that is for Activate(), which is specifically mentioned in a comment somewhere as bypassing the delay.

On SetCustomProxy() my logic was: if you change proxies then of course traffic management to the old proxy would be irrelevant, so you probably would reset the delay period when SetCustomProxy() is called. Oh well, that idea is out as well then.

I really hate having the comms check function need to know why I want to check the comms. It just instinctively seems like bad design to me. I assume you must understand that, because ISTM the TurboActivate API has been designed with OOD principles in mind (i.e. minimal exchange of data between agents). But, if that's the way it is then I'll just have to grin and bear it.

p.s. The above discussion may make it appear that I'm ungrateful - I'm not! I have incorporated online activation into our app with remarkably little fuss. The stuff I'm doing now is just poking around the edges of a substantially working feature: a few people (all working for one company) can't activate, that's all.

p.p.s. Oh, I just noticed - no bbcode? This is clearly a phpBB forum, it so happens that I'm setting one up myself. You disabled bbcodes in the admin panel? But you allow smilies? I'd rather have it the other way myself! 😉

>> "Are you saying that IsGenuineEx() is the only function that tries to manage traffic to the servers? I somehow got the impression that most functions did (if they can fail with an INET error). Except that is for Activate(), which is specifically mentioned in a comment somewhere as bypassing the delay."

Yes, IsGenuineEx() is the only one that delays on retry in order to prevent hammering of the customer's local network. The reason is that IsGenuineEx() is designed to be run at the start of every app, and rather than have every customer write boilerplate that prevents hammering, we just built it into the function.

But it tells you when it's not contacting the servers. It returns TA_E_INET_DELAYED. And if you can take the appropriate action upon getting that return code (namely, prompting the user, and then calling IsGenuine() to re-check immediately).

>> "I really hate having the comms check function need to know why I want to check the comms. It just instinctively seems like bad design to me."

It doesn't need to know why you're calling it. It already knows implicitly why you're calling it (because the function has a known purpose).

The reason we don't (and won't) have a general purpose "ping" function is because it wouldn't give actionable information. It's like checking if a filename exists before doing some action on it. It's an ultimately pointless action because the time between when you do that check and you do that action the file may or may not exist.

In other words, it's better to do the action and handle the failure, rather than checking if the action is possible and then assuming it will work (and *still* needing to handle the failure).

>> "a few people (all working for one company) can't activate, that's all."

Have them type wyday.com in Internet Explorer. Does it load? Or does it show some sort of blocked error message?

https://wyday.com/limelm/help/faq/#internet-error

>> "Oh, I just noticed - no bbcode?"

No, phpBB is terrible. There are too many problems that go with enabling bbcode (including failing to compile on the latest php). We're switching away from phpBB to a custom solution.

If I were to recommend a forum software, use Vanilla. Avoid phpBB at all costs.

Wyatt wrote:> The reason we don't (and won't) have a general purpose "ping" function is> because it wouldn't give actionable information. It's like checking if a filename> exists before doing some action on it.I'm sorry, but I don't agree. Pinging the server proves that a not terribly computer literate user has typed in the proxy details correctly, and that your server is now (in principle) contactable. I'm not looking for a lifetime guarantee.

I'm not looking for a general purpose ping either, just something that is guaranteed to contact the server and be non destructive (i.e. not changing the activation state of the user, who may not have typed in his details yet). For example, a GetTimeFromServer() function would have many uses, including this.

Wyatt wrote:> If I were to recommend a forum software, use Vanilla. Avoid phpBB at all costs.Too late. Forum has been up and running for several days, I'm not tearing it down now! (but thanks for the advice).

, edited

We'll think about adding something like that.