Cannot run kdb 64bit behind a proxy

[pineBear123]

Hi, 

I get an error message about connecting to a licensing server when running a 64bit version of kdb on Windows 10. I am a grad student using a corporate laptop. I don't see a way to configure KDB to use a proxy.  The Internet connectivity is there. The proxy setting in Windows is configured to use a script at a particular address (automatic proxy setting with the script).

Does kbd support proxies? How would I configure it to use a particular proxy? I want to use 64 bit kdb since I plan to experiment with jupyterq that does not support 32 bit kdb. 

"'2022.03.09T15:28:47.728 couldn't connect to license daemon -- exiting"

Thanks

[pineBear123 · Accepted solution]

Ping works fine (as seen below). I also added an entry to windows firewall to allow network access to q.exe. The issue must be with the proxy, I just want to see what q sees.

I looked in registry and AutoConfigURL for proxy is http://xyz/abc.pac. The pack file has the rules for proxying. I am guessing that might be an issue. 

Pinging dy2kttecucxn3.cloudfront.net [13.249.90.90] with 32 bytes of data:
Reply from 13.249.90.90: bytes=32 time=13ms TTL=237
Reply from 13.249.90.90: bytes=32 time=12ms TTL=237
Reply from 13.249.90.90: bytes=32 time=12ms TTL=237
Reply from 13.249.90.90: bytes=32 time=12ms TTL=237

Ping statistics for 13.249.90.90:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 13ms, Average = 12ms

[pineBear123]

Forgot to mention. I tried setting an environment variable HTTP_PROXY=http://myproxy.com:8090 but that did not work. That's the proxy I used for Python's pip

[rocuinneagain]

The email you received with your kc.lic included some details on this topic:

Generally, kdb+ as an on-demand client behaves exactly like, and should be treated the same as, any plain http client (e.g. curl, apt-get or firefox) accessing a CDN-fronted web service.
It connects to a remote port 80 as part of a normal http request; thus you generally only need to allow outbound http _connections_ but both _traffic_ to and from remote port 80.
As the communication protocol is plain http you can employ any standard mechanism, including proxies (transparent and opaque by setting the HTTP_PROXY environment variable) as long as kdb+ is able to issue an http request and receive a response from the remote Kx service.
If you need to allowlist the remote servers should treat kdb+ on-demand as a CDN-fronted service and employ DNS-based filtering. The current list of hostnames required for kdb+ on-demand operation is {h,g}.kdbod.{com,net,org}.

[pineBear123]

Is there a way to run q.exe with some verbose logging to see where the connectivity breaks? I tried setting http proxy via "set HTTP_PROXY=http://xyz:1080" and using -l option for logging, but the log file is not created.

[rocuinneagain]

Can you confirm you can access {h,g}.kdbod.{com,net,org}  on 80?

Can you ping them from your shell?

ping g.kdbod.com

[pineBear123 · Accepted solution]

Ping works fine (as seen below). I also added an entry to windows firewall to allow network access to q.exe. The issue must be with the proxy, I just want to see what q sees.

I looked in registry and AutoConfigURL for proxy is http://xyz/abc.pac. The pack file has the rules for proxying. I am guessing that might be an issue. 

Pinging dy2kttecucxn3.cloudfront.net [13.249.90.90] with 32 bytes of data:
Reply from 13.249.90.90: bytes=32 time=13ms TTL=237
Reply from 13.249.90.90: bytes=32 time=12ms TTL=237
Reply from 13.249.90.90: bytes=32 time=12ms TTL=237
Reply from 13.249.90.90: bytes=32 time=12ms TTL=237

Ping statistics for 13.249.90.90:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 13ms, Average = 12ms

[pineBear123 · Accepted solution]

I read proxy's pac file and figured out the right proxy to use. Using that as the HTTP_PROXY solved the problem. If there are issues with the connection on the start-up, the log is not created however. 

Thank you