| … | … | @@ -712,3 +712,38 @@ failing run used the mutated build as intended — but "restoring the fixed |
| 712 | 712 | binary" restored the broken one. Caught by md5-ing all three; the tracked |
| 713 | 713 | binary is now rebuilt from verified-clean source. Copy a binary before you |
| 714 | 714 | overwrite it, not after. |
| 715 | |
| 716 | ### 11.1 ⚠ CORRECTION to §11: JS is not "immediate", it is 10-15 seconds |
| 717 | |
| 718 | §11 said JS "releases on the connection's own close event, guaranteed and |
| 719 | immediate — milliseconds for a refused or unreachable peer". That overstated it, |
| 720 | and the overstatement was committed before it was checked. |
| 721 | |
| 722 | Read at source in `hyperdht/lib/connect.js`: |
| 723 | |
| 724 | c.passiveConnectTimeout = setTimeout(onabort, 10000) // :244, FIREWALL.OPEN |
| 725 | c.relayTimeout = setTimeout(onabort, 15000) // :812, relay path |
| 726 | c.relayClient.pair(...).on('error', onabort) // :814, explicit error |
| 727 | |
| 728 | `onabort` destroys the session, the stream closes, and `close` fires |
| 729 | `_connectDone()`. So the release IS event-driven, but the event is usually a |
| 730 | JS-side timer, not the network. |
| 731 | |
| 732 | The accurate comparison: |
| 733 | |
| 734 | | case | JS | ours | |
| 735 | |---|---|---| |
| 736 | | explicit error (relay refuses, socket error) | immediate | **30s** | |
| 737 | | unresponsive peer, open firewall | 10s | 30s | |
| 738 | | unresponsive peer, relay path | 15s | 30s | |
| 739 | | holepunch abort | immediate | immediate (`puncher.on_abort`) | |
| 740 | |
| 741 | So the gap is 2-3x on the common path plus immediate-vs-30s on explicit errors — |
| 742 | real, and materially smaller than §11 claimed. With `SWARM_MAX_PARALLEL = 3` it |
| 743 | still means our outbound capacity recovers two to three times more slowly from a |
| 744 | topic carrying stale records, which is why it compounds with defect B. |
| 745 | |
| 746 | ⛔ It also changes the FIX. "Release on stream close" is not right: a connect |
| 747 | attempt that never opened has no stream to close. What we lack is (a) an |
| 748 | explicit-error path that aborts without waiting, and (b) a connect timeout in |
| 749 | JS's range rather than 30s. Those are two separate changes with separate gates. |