Concurrent Connections from Same Device

Technical Help
#1

I have a script setup on my local device that runs ml_walkforward against my cloud server. I want to run multiple simultaneous ml_walkforward runs against the server in parallel from my local device. However, when I try this I get the max concurrent installs is two error. Is this expected behavior? The docs don't clarify how many open connections and requests I can make from the second device. If not how do you suggest running multiple requests from the same remote device to run multiple backtests? Thanks!

#2

The cloud server is 1 concurrent install and the remote connection to it from your local device counts as a second concurrent install, as described here. There is no limit on the number of simultaneous requests running on the cloud server, or coming from the local device to the cloud server. If all you have is QuantRocket running on 1 cloud server, plus 1 local device that is not running QuantRocket but is making requests to the cloud server, there's shouldn't be a max concurrent installs error. Is there anything else running QuantRocket or making requests to the cloud server?

#3

Hmmmm. I'm sure that I don't have any other instances running. The behavior is quite flaky. I arbitrarily get the two concurrent installs error. Do you have any suggestions on how to debug this or figure out why I am getting this two concurrent installs error when at any time I only have two devices (the cloud server, my laptop).

#4

So the concurrent installs comes from internet probes. One of the IPs is an internet probe the other is AWS. Is there any particular reason that Quant Rocket is picking up a probe connecting to the server as a concurrent install?

IP: 91.196.152.209

  • Reverse DNS (PTR): edith.probe.onyphe.net.
  • Owner (WHOIS/RIPE): ONYPHE SAS (France)
  • Netblock: 91.196.152.0 - 91.196.152.255 (91.196.152.0/24)
  • ASN (route origin): AS213412
  • Opt-out contact (per WHOIS remarks): [email protected]
  • Geo (IP geolocation, approximate): Roubaix, Hauts-de-France, FR
#5

I am pretty sure I can resolve this by just changing my server to IP whitelist and am trying that, but I don't think it makes sense for the QR service to count any connections to the server its hosted on as a concurrent install as that what it seems like the behavior is. Maybe I'm wrong not sure. Thanks for the replies!

#6

Thanks for reporting this, and I apologize for the inconvenience.

Currently QuantRocket doesn't distinguish between probes and "real" requests, which is why the probes were able to take one of your slots. We will improve the logic in the next release to better distinguish the type of traffic so this doesn't happen.

Regardless, your solution of whitelisting trusted IPs and blocking everything else is the best solution and is what I recommend for cloud servers, as it's good to block the probe traffic anyway.

#7

While working on doing this, it seems this may cause issues with lets encrypt. Any suggestions on how to do ingress, egress in such a way that it resolves this issue and doesn't break a cert renewal? Also any further information you are willing to disclose on how Quantrocket decides what an install is would be helpful. I.e. is it counting distinct IPs for requests made to :443 or :80 or both?

#8

Port 80 should remain open for the sake of Let's Encrypt cert renewal. Nothing listens on 80, so there is no security risk. Detailed information on opening ports can be found in the QR installation tutorial for Oracle Cloud.

Concurrent installs are based on MAC address and/or IP and are only counted for port 443, not 80.

#9

Thanks!