Hello everyone,
I am excited to share some recent updates from the Boundary Node team.
Progress:
We’ve completed the development of our custom router ic-boundary and successfully integrated it into the existing boundary nodes. Currently, our focus is on finalizing everything necessary to put the API boundary nodes under the NNS.
ic-boundary
After extensive testing, we have deployed ic-boundary to all production boundary nodes. This means that all API requests (status, query, call, and read_state) are now handled by ic-boundary. The deployment has been smooth, and the robustness of the boundary nodes improved significantly. Previously encountered memory peaks with nginx, leading to occasional out-of-memory issues, have been resolved, resulting in stable memory consumption.
The decision to replace nginx with a custom router appears to be a successful one. This transition has also enabled us to implement highly requested improvements, such as automatic retries in case of errors from the replica. These enhancements will be rolled out in the upcoming days as we apply the final touches and address any remaining small bugs.
Preparing NNS-management
Our primary focus is on preparing for the deployment of the first NNS-managed API boundary nodes. However, there are a few projects we need to complete before achieving this milestone:
- Orchestrator: Collaborating with the consensus team, we are extending the orchestrator to start
ic-boundarywhen a node becomes an API boundary node and properly shut it down if the node becomes unassigned. Additionally, we are enhancing the orchestrator’s firewall service to apply the right configuration (i.e., open up HTTP(S) to the public) depending on the node type. - IPv4-enabled Nodes: To ensure API boundary nodes can serve everyone, they require an IPv4 address. We are working with the node team on a general feature allowing any IC node to have an IPv4 address, making it suitable for API boundary nodes or inclusion in an IPv4-enabled subnet.
- Discovery Library: We are developing a library to assist IC clients in discovering existing API boundary nodes and routing their traffic to them. The library consists of two parts: discovery and routing. The discovery component involves obtaining a full list of API boundary nodes from the NNS in a certified manner, starting with a seed list. The routing component determines the optimal API boundary node from the list for directing all API requests. The library offers various ways to select a suitable node, such as any healthy node or the one with the lowest latency.
Outlook:
With the successful deployment of ic-boundary in the production boundary nodes, we are approaching the deployment of the first fully NNS-managed API boundary node. There are still a few items to address on our checklist, and we anticipate rolling them out early in 2024.
In the near future, we will begin exploring ic-gateway (working title), the counterpart of ic-boundary, implementing the HTTP gateway protocol and serving as the core of the HTTP gateways.
We will continue to keep you updated on our progress and look forward to hearing your feedback and addressing any questions you may have!