-* PEERINFO:
- - trust: need *fast* way to check/update trust in peers
- (async peerinfo would not be right; certainly not with the
- current API)
-* UTIL:
- - scheduler should change OS process priority based on task priority;
- should make better use of task priorities in general
- - only connect() sockets that are ready (select()) [Nils]
- [On W32, we need to select after calling socket before
- doing connect etc.]
-* SETUP:
- - design & implement new setup tool
-* TBENCH: [MW]
- - good to have for transport/DV evaluation!
-* DV: [Nate]
- - write DV API (need to move declarations from dv_api.c to gnunet_dv_service.h!)
- - implement DV service
- - implement DV library (looks done)
- - implement DV transport plugin
- - implement testcases
- - implement performance tests
-* STATISTICS:
- - does not seem to work with timeouts (especially if service is not running)
-* TOPOLOGY:
- - needs more testing (especially F2F topology)
- - needs to re-try connecting after disconnect (currently, it
- initially triggers a connection request, but if that connection
- fails / goes down, it does not retry in a timely fashion;
- cause seems to be the 'blacklist_after_attempt' being set to 1h,
- which is rather long -- and should probably be adjusted based on
- the number of connections / known peers)
- - If the topology daemon crashes, peers that were put on the
- blacklist with transport will never be removed from it (until
- transport service dies); we should use the blacklist notification
- API to learn about the exact set of blacklisted peers at all times
- (FIXME: the transport_api implementation of blacklisting
- also does not work nicely for this since it won't let us know about
- disconnect-reconnect events and the implicit whitelisting
- that might happen here; that's not so bad since we will
- re-blacklist on pre-connect attempts anyway, so this is
- a minor issue; OTOH, we might want to be more explicit about
- allowing/forbidding connects on pre-connect to avoid
- entering connect attempts to just be blacklisted shortly afterwards).
- - the code uses the term 'blacklist' for both peers that are forbidden
- to connect (i.e. F2F mode) as well as peers that we currently
- won't try to actively connect to ourselves (since we just tried);
- This is confusing. We need two distinct terms (greylist?).
- - move code to use hash table instead of linked list
- - instead of periodically discarding blacklisted entries,
- simply add task that is triggered at the right time (earlier free,
- more balanced load)
- - check if new HELLO learned is different from old HELLO
- before resetting entire state!
+* DATASTORE [CG]
+ - move request queuing functionality into the API library
+* MIGRATION [CG]
+ - on-demand encoding => move logic to block-library!?
+ - peer selection => how to consider latency/bw/etc?
+ - content transmission => how often the same block?
+ - how to select delay before next migration?
+ - migration to us
+ - testing
+ - integrate with FS or not? (peer list, index/on-demand encoding, block code,
+ inbound priority assignment; all would be easier with tight integration!)