mirror of
https://github.com/YGGverse/aquatic.git
synced 2026-03-31 17:55:36 +00:00
3.1 KiB
3.1 KiB
TODO
aquatic_ws
- ipv4 / ipv6 split state?
- network
- handle tls certificate parse errors etc better
- parse once only
- exit with error message, not with panic
- handle socket binding errors better (print them and exit)
- send/recv buffer size config
- limit ws message sizes?
- handle tls certificate parse errors etc better
- privdrop
aquatic_udp
- mio: set oneshot for epoll and kqueue? otherwise, stop reregistering?
- Handle Ipv4 and Ipv6 peers. Probably split torrent state. Ipv4 peers can't make use of Ipv6 ones. Ipv6 ones may or may note be able to make use of Ipv4 ones, I have to check.
- More tests?
bittorrent_udp
- Tests with good known byte sequences (requests and responses)
Not important
aquatic_ws
- some config.network fields are actually used in handler. maybe they should be checked while parsing? not completely clear
- "close connection" message from handler on peer_id and socket_addr mismatch? Probably not really necessary. If it is an honest mistake, peer will just keep announcing and after a few minutes, the peer in the map will be cleaned out and everything will start working
- log crate instead of println/eprintln?
aquatic_udp
- Does it really make sense to include peer address in peer map key? I have to think about why I included it in the first place.
- if socket workers panic while binding, don't sit around and wait for them in privdrop function. Maybe wait some maximum amount of time?
- No overflow on instant + duration arithmetic now, hopefully? Possibly, checked_add should be used.
- extract_response_peers
- Cleaner code
- Stack-allocated vector?
- Use log crate for errors, including logging thread names? I could probably use code from old rs_news project for that.
- Performance
- cpu-target=native good?
- mialloc good?
- Try using flume (MPSC) or multiqueue2 (MPMC) instead of crossbeam channel
bittorrent_udp
- Avoid heap allocation in general if it can be avoided?
- request from bytes for scrape: use arrayvec with some max size for torrents? With Vec, allocation takes quite a bit of CPU time
- Optimize bytes to scrape request: Vec::with_capacity or other solution (SmallVec?)
- Don't do endian conversion where unnecessary, such as for connection id and transaction id?
cli_helpers
- Include config field comments in exported toml (likely quite a bit of work)
Don't do
aquatic_udp
- Other HashMap hashers (such as SeaHash): seemingly not worthwhile, see
https://github.com/tkaitchuck/aHash sendmmsg: can't send to multiple socket addresses, so doesn't help- Config behind Arc in state: it is likely better to be able to pass it around without state
- Responses: make vecors iteretor references so we dont have run .collect(). Doesn't work since it means conversion to bytes must be done while holding readable reference to entry in torrent map, hurting concurrency.
bittorrent_udp
- Use
bytescrate for bittorrent_udp: seems to worsen performance somewhat - Zerocopy (https://docs.rs/zerocopy/0.3.0/zerocopy/index.html) for requests and responses? Doesn't work on Vec etc
- New array buffer each time in response_to_bytes: doesn't help performance