Help us test ic-gateway, the core of the upcoming HTTP gateways

Developers
1

Hello everyone,

I am happy to share that we took another big step towards the new boundary node architecture: the completion of internal testing for ic-gateway, the core service of the upcoming HTTP gateways. For more details on the new architecture and the HTTP gateway’s role, please refer to the boundary node roadmap.

Before we roll out the HTTP gateways, we need to test ic-gateway in the existing boundary nodes. To this end, we rebuilt the boundary nodes to solely rely on ic-gateway and ic-boundary (the core service of the API boundary nodes). Essentially, ic-gateway replaces nginx and icx-proxy: at a high-level, this means, it terminates TLS, caches static HTTP assets, implements the HTTP gateway protocol, and proxies the traffic to ic-boundary.

Now, we need your help: before adding these modified boundary nodes to the production load balancer, we want to test them on their own. To this end, we have setup a simple proxy configuration that routes all IC traffic to that modified boundary node. Setting up the proxy is straightforward, and instructions for Windows, Mac, and Linux are provided below.

Please give it a try and report any issues in this thread. Don’t forget to undo the changes after you’re done testing.

Thanks a lot for your help!

Mac OS X

  • Open your system settings and go to “Network” → “Wi-Fi”.
  • Select your currently active Wi-Fi connection and click on “Details”.
  • Under “Proxies” enable “Automatic proxy configuration” and provide the following URL for the proxy file:
    https://gist.githubusercontent.com/r-birkner/2baaf38ca9ce5d1135bf90ad9579c2b5/raw/6dd4288321733632376854b71089bcc20847fbec/canary-fallback.pac
  • Click on “OK” to confirm the changes.
  • Now, you are all set! From now on, all your IC traffic is proxied through the canary boundary node.

Windows

  • Open the Settings app and go to “Network & Internet” → “Proxy”.
  • Enable “Automatically detect settings”.
  • Enable “Use setup script”.
  • Set the following as “Script address”.
    https://gist.githubusercontent.com/r-birkner/2baaf38ca9ce5d1135bf90ad9579c2b5/raw/6dd4288321733632376854b71089bcc20847fbec/canary-fallback.pac
  • Click on “Save” to confirm the changes.
  • Now, you are all set! From now on, all your IC traffic is proxied through the canary boundary node.

Linux

  • Open your system settings and go to “Network” → “Network Proxy”.
  • Select “Automatic” and provide the following URL for the proxy file:
    https://gist.githubusercontent.com/r-birkner/2baaf38ca9ce5d1135bf90ad9579c2b5/raw/6dd4288321733632376854b71089bcc20847fbec/canary-fallback.pac
  • Close the settings windows.
  • Now, you are all set! From now on, all your IC traffic is proxied through the canary boundary node.
11 Likes
2

I will give this a try tomorrow.

1 Like
3

I have set it up. Should I notice a difference?

4

Hey @Forreal

Ideally, you shouldn’t note any difference. To make sure that you are really using the canary boundary node, you can open a site hosted on the IC (e.g., internetcomputer.org) and then check in the network pane of the developer tools what the “remote address” of the request is. It should be 193.118.63.171:8888.

Thanks a lot for giving it a try!

1 Like
6

Hi Rüdiger,

Have enabled the Proxy as you mentioned and opened several IC websites and raw addresses.

All worked well and no significant difference was detected, initially I thought it was faster, but when I timed it and compared on Network Tab, wasn’t able to “prove” my wishful feeling :sweat_smile:

I recorded 2 sessions, one before and another after the proxy being enabled.

Before proxy: BN Testing - without Proxy | Loom
After proxy: BN Testing - with Proxy | Loom

Hope this is somewhat helpful :pray:

Regards,
Tiago

PS.: Kudos for the PT ICP HUB for having reached out (I confess I had seen this forum post and then forgotten :sweat_smile: )

3 Likes
7

Thanks a lot @tiago89

The latency shouldn’t differ much as everything is dominated by the network latency between the boundary node and the replica. Since the boundary nodes randomly choose the replica, the latency can vary form few tens of ms to hundreds of ms.

The reason why we switched to the new gateway is mostly convenience and maintainability. Until now, we have been using nginx with custom modules. These custom modules have been necessary as nginx doesn’t support certain IC/web3 features out of the box. The custom modules were cumbersome to maintain and inefficient.

2 Likes