Change Details

The purpose of this improvement is to address: when connecting to a node that can establish a WebSocket connection (_websocketUrlConnects) but immediately throws onerror or onclose after connection, and there are no available nodes before its index, this failure will continue to loop. When there are one or more such faulty nodes, this will consume a large amount of resources. When there are no available nodes before this faulty node but there are available nodes after it, it won't switch correctly. The solution is to add a delay using setTimeout (which may also prevent stack overflow issues in extreme cases, though uncertain) while ensuring node switching. Dynamic fallback delay calculation is used to adjust delay time based on different number of nodes. For example, with only 1 node, it will continue trying with a 500ms delay - it won't exit but at least won't cause the aforementioned issues. With 5 nodes, the base delay is 500/square of node count, which is 20ms, then the delay time varies according to different this._workingIndex values (0 to 4): When this._workingIndex = 0: 20 * 1 = 20ms When this._workingIndex = 1: 20 * 2 = 40ms When this._workingIndex = 2: 20 * 3 = 60ms When this._workingIndex = 3: 20 * 4 = 80ms When this._workingIndex = 4: 20 * 5 = 100ms The purpose is to avoid switching nodes too quickly when all nodes are unavailable (can pass _websocketUrlConnects but actually faulty) while maintaining retry efficiency. For example, 1 node takes 500ms, 2 nodes take 125+250=375ms, 3 nodes take 55+111+166=332ms. This solution can solve the aforementioned issues. It allows the reconnection mechanism to function properly in various situations without getting stuck in resource-intensive loops.

The purpose of this improvement is to address the following issue: When connecting to a node that can establish a WebSocket connection (_websocketUrlConnects) but immediately throws onerror or onclose after connection, the system will keep attempting to reconnect to this faulty node instead of switching to another one, until the WebSocket connection itself fails to establish. This leads to high-frequency requests to the faulty node when it's the only URL available, consuming significant resources, while also failing to properly switch to available nodes when the faulty node cannot switch correctly. The solution is to add a delay using setTimeout (which may also prevent stack overflow issues in extreme cases, though uncertain) while ensuring node switching. Dynamic fallback delay calculation is used to adjust delay time based on different number of nodes. For example, with only 1 node, it will continue trying with a 500ms delay - it won't exit but at least won't cause the aforementioned issues. With 5 nodes, the base delay is 500/square of node count, which is 20ms, then the delay time varies according to different this._workingIndex values (0 to 4): When this._workingIndex = 0: 20 * 1 = 20ms When this._workingIndex = 1: 20 * 2 = 40ms When this._workingIndex = 2: 20 * 3 = 60ms When this._workingIndex = 3: 20 * 4 = 80ms When this._workingIndex = 4: 20 * 5 = 100ms The purpose is to avoid switching nodes too quickly when all nodes are unavailable (can pass _websocketUrlConnects but actually faulty) while maintaining retry efficiency. For example, 1 node takes 500ms, 2 nodes take 125+250=375ms, 3 nodes take 55+111+166=332ms. This solution can solve the aforementioned issues. It allows the reconnection mechanism to function properly in various situations without getting stuck in resource-intensive loops.

The purpose of this improvement is to address: when the following issue: When connecting to a node that can establish a WebSocket connection (_websocketUrlConnects) but immediately throws onerror or onclose after connection, and there are no available nodes before its index, this failure will continuethe system will keep attempting to reconnect to this faulty node instead of switching to loop.another one, Whenuntil there are one or more such faulty nodes, WebSocket connection itself fails to establish. tThis will consume a large amount of resources.leads to high-frequency requests to the faulty node when it's the only URL available, When there are no available nodes before this faulty node but there are available nodes after itconsuming significant resources, it won'while also failing to properly switch to available nodes when the faulty node cannot switch correctly. The solution is to add a delay using setTimeout (which may also prevent stack overflow issues in extreme cases, though uncertain) while ensuring node switching. Dynamic fallback delay calculation is used to adjust delay time based on different number of nodes. For example, with only 1 node, it will continue trying with a 500ms delay - it won't exit but at least won't cause the aforementioned issues. With 5 nodes, the base delay is 500/square of node count, which is 20ms, then the delay time varies according to different this._workingIndex values (0 to 4): When this._workingIndex = 0: 20 * 1 = 20ms When this._workingIndex = 1: 20 * 2 = 40ms When this._workingIndex = 2: 20 * 3 = 60ms When this._workingIndex = 3: 20 * 4 = 80ms When this._workingIndex = 4: 20 * 5 = 100ms The purpose is to avoid switching nodes too quickly when all nodes are unavailable (can pass _websocketUrlConnects but actually faulty) while maintaining retry efficiency. For example, 1 node takes 500ms, 2 nodes take 125+250=375ms, 3 nodes take 55+111+166=332ms. This solution can solve the aforementioned issues. It allows the reconnection mechanism to function properly in various situations without getting stuck in resource-intensive loops.