Cyber/ravenscott-blog
1
0
Fork 0
forked from snxraven/ravenscott-blog
Code Pull Requests Activity

update

Browse Source
This commit is contained in:
Raven Scott 2024-11-09 00:49:11 -05:00
parent 4205593761
commit 3886e95f23
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
markdown/Hyper Protocol: Enhancing Tunnel Isolation and Port Management in Node.js Clustered Applications.md
View File

@ -1,7 +1,7 @@
<!-- lead --> <!-- lead -->
Streamlining Node.js Tunnels: Isolation, port management, and resource efficiency for peak performance! Streamlining Node.js Tunnels: Isolation, port management, and resource efficiency for peak performance!
In this post, we’ll dive deeply into recent optimizations made to a Node.js clustered application managing tunneled requests with isolated connections. We’ll explore the issues with the initial setup, outline each enhancement in detail, and contrast the old and new methods. These changes aim to improve tunnel isolation, streamline resource management, and prevent critical errors that could disrupt the application’s operation. In this post, I dive deeply into recent optimizations made to a Node.js clustered application managing tunneled requests with isolated connections. I explore the issues with the initial setup, outline each enhancement in detail, and contrast the old and new methods. These changes aim to improve tunnel isolation, streamline resource management, and prevent critical errors that could disrupt the application’s operation.
# Source # Source
## https://git.ssh.surf/hypermc/hyperMC-Web-Relay ## https://git.ssh.surf/hypermc/hyperMC-Web-Relay
@ -18,7 +18,7 @@ Our application originally served HTTP requests over a peer-to-peer network usin
1. **Clustered Node.js Workers**: Using `cluster`, the application spawns multiple workers, leveraging all CPU cores for better concurrency and faster request handling. 1. **Clustered Node.js Workers**: Using `cluster`, the application spawns multiple workers, leveraging all CPU cores for better concurrency and faster request handling.
2. **HyperDHT Tunnels**: For each request, the application creates a tunnel to relay data between the client and the destination using the `hyperdht` protocol. 2. **HyperDHT Tunnels**: For each request, the application creates a tunnel to relay data between the client and the destination using the `hyperdht` protocol.
3. **Port Management for Tunnels**: To assign ports for tunnel servers, we used randomly generated port numbers within a specified range. 3. **Port Management for Tunnels**: To assign ports for tunnel servers, I used randomly generated port numbers within a specified range.
### The Problem ### The Problem
@ -36,13 +36,13 @@ As the application scaled, several issues began to emerge:
- Tunnels remained open even after requests completed, resulting in unnecessary resource consumption. - Tunnels remained open even after requests completed, resulting in unnecessary resource consumption.
- Workers were busy managing unused connections instead of handling new requests, leading to performance bottlenecks. - Workers were busy managing unused connections instead of handling new requests, leading to performance bottlenecks.
Given these challenges, we set out to improve tunnel isolation, ensure reliable port availability, and enhance resource efficiency. Given these challenges, I set out to improve tunnel isolation, ensure reliable port availability, and enhance resource efficiency.
## New Approach: Enhanced Isolation, Dynamic Port Allocation, and Resource Management ## New Approach: Enhanced Isolation, Dynamic Port Allocation, and Resource Management
To tackle these issues, we implemented several key improvements: To tackle these issues, I implemented several key improvements:
### 1. Strict Tunnel Isolation Per Request ### 1. Strict Tunnel Isolation Per Request
@ -73,7 +73,7 @@ With this change, each tunnel becomes ephemeral, existing solely to complete a s
In the initial implementation, the application generated random ports without checking their availability, leading to frequent `EADDRINUSE` errors. To address this: In the initial implementation, the application generated random ports without checking their availability, leading to frequent `EADDRINUSE` errors. To address this:
- **Port Checking with `net.createServer`**: We enhanced `getAvailablePort` by creating a temporary server to verify port availability. If the port is free, the function closes the test server and assigns that port to the new tunnel. If the port is already in use, it retries until it finds a free port. - **Port Checking with `net.createServer`**: I enhanced `getAvailablePort` by creating a temporary server to verify port availability. If the port is free, the function closes the test server and assigns that port to the new tunnel. If the port is already in use, it retries until it finds a free port.
- **Automatic Retry Mechanism**: This approach ensures no `EADDRINUSE` errors by dynamically testing ports until an available one is found. - **Automatic Retry Mechanism**: This approach ensures no `EADDRINUSE` errors by dynamically testing ports until an available one is found.
**Code Difference**: **Code Difference**:
@ -272,7 +272,7 @@ if (cluster.isMaster) {
## Final Thoughts ## Final Thoughts
The new design introduces strict isolation for tunnels, efficient port management, and automatic resource cleanup. By implementing these changes, we: The new design introduces strict isolation for tunnels, efficient port management, and automatic resource cleanup. By implementing these changes, I:
- Solved the `EADDRINUSE` errors by dynamically checking port availability. - Solved the `EADDRINUSE` errors by dynamically checking port availability.
- Isolated tunnels to prevent cross-request data confusion. - Isolated tunnels to prevent cross-request data confusion.
- Enhanced performance and scalability by closing tunnels immediately after requests finish. - Enhanced performance and scalability by closing tunnels immediately after requests finish.