YGGverse/aquatic
1
0
Fork 0
mirror of https://github.com/YGGverse/aquatic.git synced 2026-03-31 17:55:36 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update TODO

Browse source
This commit is contained in:
Joakim Frostegård 2020-07-21 02:00:15 +02:00
parent fcf1ecf0e8
commit 773494b17b
1 changed files with 5 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

24
TODO.md
View file

@ -10,27 +10,24 @@
## aquatic_http_load_test ## aquatic_http_load_test
* 80k responses per second is possible (as long as those weren't errors). * 80k responses per second is possible with low poll timeout values. Probably
Probably has to do with exact timing of receiving responses and sending has to do with exact timing of receiving responses and sending requests.
requests.
* think about when to open new connections * think about when to open new connections
* requests per seconds only goes up with lower poll timeout in tracker or
more connections (if they don't all send stuff at the same time), in my
understanding
* opening new connections in current form causes macOS issues, why? * opening new connections in current form causes macOS issues, why?
## aquatic_http ## aquatic_http
* upper limit on request read buffer * upper limit on request read buffer
* request parsing: * request parsing:
* smartstring: maybe use for keys? maybe use less? needs benchmarking * smartstring: maybe use for keys? maybe use less? needs benchmarking
* test multiple scrape hashes
* test with strange/bad inputs, with and without quickcheck * test with strange/bad inputs, with and without quickcheck
* test torrent transfer with real clients * test torrent transfer with real clients
* test tls * test tls
* current serialized byte strings valid * current serialized byte strings valid
* scrape: does it work (serialization etc), and with multiple hashes? * scrape: does it work (serialization etc), and with multiple hashes?
* compact=0 should result in error response * 'left' optional in magnet requests? Probably not. Transmission sends huge
positive number.
* tests of response serialization (against data known to be good would be nice) * tests of response serialization (against data known to be good would be nice)
* compact=0 should result in error response
* Connection.send_response: handle case when all bytes are not written: can * Connection.send_response: handle case when all bytes are not written: can
write actually block here? And what action should be taken then? write actually block here? And what action should be taken then?
@ -38,18 +35,7 @@
* use fastrand instead of rand? (also for ws and udp then I guess because of * use fastrand instead of rand? (also for ws and udp then I guess because of
shared function) shared function)
* use smartstring crate for failure response reason? * use smartstring crate for failure response reason?
* request parsing in protocol module instead of in network, maybe from byte
buffer? Not obvious what error return type to use then (anyhow maybe?)
* log more info for all log modes (function location etc)? also for aquatic_ws * log more info for all log modes (function location etc)? also for aquatic_ws
* move stuff to common crate with ws?
* serialization for future load tester: write custom non-serde serializer
for url encode support maybe, or possibly existing crates handle byte
serialization well (then there would still be the question of multiple
values per key for scrape requests)
* 'left' optional in magnet requests? Probably not. Transmission sends huge
positive number.
* handle_connection_read_event: this is an ugly function, but I don't know
how to improve it
* Support supportcrypto/requirecrypto keys? Official extension according to * Support supportcrypto/requirecrypto keys? Official extension according to
https://wiki.theory.org/index.php/BitTorrentSpecification#Connection_Obfuscation. https://wiki.theory.org/index.php/BitTorrentSpecification#Connection_Obfuscation.
More info: http://wiki.vuze.com/w/Message_Stream_Encryption. The tricky part More info: http://wiki.vuze.com/w/Message_Stream_Encryption. The tricky part