Update TODO

This commit is contained in:
Joakim Frostegård 2020-08-03 07:27:55 +02:00
parent 6f618bb013
commit 94bc33ea72

View file

@ -35,14 +35,15 @@
write actually block here? And what action should be taken then? write actually block here? And what action should be taken then?
## aquatic_ws ## aquatic_ws
* what does numwant actually do? * tests for request/response serialization and deserialization
* add Arbitrary instances, add conversion identity tests
* what does numwant do in reference tracker? number of offers to send, right?
* test transfer again with changes made: * test transfer again with changes made:
* crossbeam-channel * crossbeam-channel
* ipv6/ipv4 mapping * ipv6/ipv4 mapping
* tungstenite 0.11 * tungstenite 0.11
* is 'key' sent in announce request? if so, maybe handle it like in * is 'key' sent in announce request? if so, maybe handle it like in
aquatic_http (including ip uniqueness part of peer map key) aquatic_http (including ip uniqueness part of peer map key)
* tests
* config: multiple request workers * config: multiple request workers
* optimize serialize_20_bytes (10% cpu utilization). deserialize_20_bytes * optimize serialize_20_bytes (10% cpu utilization). deserialize_20_bytes
doesn't seem to be that expensive (1-2% cpu) doesn't seem to be that expensive (1-2% cpu)
@ -52,6 +53,8 @@
* why does wt-tracker freak out when numwant is set to offers.len()? lots * why does wt-tracker freak out when numwant is set to offers.len()? lots
of broken pipe errors etc. likely because it sends offers when it is set. of broken pipe errors etc. likely because it sends offers when it is set.
* wt-tracker: why lots of responses with no (new) requests? * wt-tracker: why lots of responses with no (new) requests?
* offers_per_request or similar config var
* consider writing custom serializers, they take up lots of time now
## aquatic_udp ## aquatic_udp
* handle errors similarily to aquatic_ws, including errors in socket workers * handle errors similarily to aquatic_ws, including errors in socket workers