Opened 5 years ago
Closed 5 years ago
#1505 closed defect (fixed)
Add new Bloom filter setting, raise BW limit
| Reported by: | zzz | Owned by: | zzz |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.9.21 |
| Component: | router/general | Version: | 0.9.18 |
| Keywords: | Cc: | ||
| Parent Tickets: | Sensitive: | no |
Description
Related: #1447
Subtickets
Change History (4)
comment:1 Changed 5 years ago by
| Status: | new → testing |
|---|
comment:2 Changed 5 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | testing → closed |
propped early in 0.9.19-x cycle
comment:3 Changed 5 years ago by
| Milestone: | 0.9.20 → 0.9.21 |
|---|---|
| Resolution: | fixed |
| Status: | closed → reopened |
Somebody on IRC has hit the new 8 MBps limit and requested and is testing a higher limit (w/o a Bloom filter change)
Doubling the Bloom filter size again would be really huge. Psi proposes a per-tunnel filter instead, presumably a HashSet?, but without any data that a) cross-tunnel (or out-of-tunnel) replay attacks are not part of our threat model; or b) per-tunnel filters would be smaller. For further research.
The next step up for the DecayingBloomFilter? would be 32 MB.
I briefly looked at using memory off-heap with a direct ByteBuffer? but BB.array() is optional and apparently not usually implemented. But we could perhaps use get/put.
comment:4 Changed 5 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
In c051f1b4a8ff522b94a2be9da03e1601b873f983 to be 0.9.20-15, upped to m=27 k=9 (32 MB) max=16384KBps
In 616a55fe09c9f3c5649ab86bfb004a38b58dd391 i2p.i2p.zzz.test2 to be propped for 0.9.20