-Implementable right now (but not necessarily important), with caveats
-(unavailable components that will limit what can be implemented right
-away), in order in which they will likely be done:
-* TESTING-TESTBED [Nate]
-* SETUP
-* DV [Nate]
-* TBENCH
-* TRACEKIT
-* FRAGMENTATION [Ji Lu]
-* HTTP transport
-* MySQL / Postgres plugins (datastore, datacache) [Radhika]
-* UPNP [Milan]
-
-Urgent items (before announcing ng.gnunet.org):
-* topology
- - needs testing
-* hostlist
- - test fails (peers don't connect quickly, could be topology issue)
- - crashes:
-(gdb) print pos
-$1 = (struct GNUNET_TRANSPORT_TransmitHandle *) 0x21
-(gdb) print h
-$2 = (struct GNUNET_TRANSPORT_Handle *) 0x21775d0
-(gdb) print *h
-$3 = {cls = 0x454d414e54534f48, rec = 0x7f66983d7e00 <_IO_stdfile_0_lock>, nc_cb = 0x4010d8 <notify_connect+128>, nd_cb = 0x21, my_hello = 0x736f686c61636f6c, client = 0x7f66983d0074, network_handle = 0x0, connect_wait_head = 0x21, connect_ready_head = 0x21775b0,
- hwl_head = 0x2177630, sched = 0x2177650, cfg = 0x21, neighbours = 0x54524f5050545448, reconnect_task = 140078617558528, reconnect_delay = {value = 1000}, transmission_scheduled = 33}
-(gdb) ba
-#0 0x00007f6698a2143c in add_neighbour (h=0x21775d0, quota_out=1, latency=..., pid=0x7fff2d320bd0) at transport_api.c:1383
-#1 0x00007f6698a21d70 in demultiplexer (cls=0x21775d0, msg=0x7fff2d320bc0) at transport_api.c:1645
-#2 0x00007f66985ed452 in receive_task (cls=0x2177470, tc=0x7fff2d320ca0) at client.c:491
-#3 0x00007f6698609caa in run_ready (sched=0x7fff2d320d10) at scheduler.c:482
-#4 0x00007f669860a0ba in GNUNET_SCHEDULER_run (task=0x7f66986069a8 <program_main>, task_cls=0x7fff2d320f20) at scheduler.c:609
-#5 0x00007f6698606ffc in GNUNET_PROGRAM_run (argc=5, argv=0x7fff2d321000, binaryName=0x401b3f "st-gnunetd-hostlist-peer-2", binaryHelp=0x401b86 "", options=0x7fff2d320fc0, task=0x401638 <run+128>, task_cls=0x602360) at program.c:223
+0.9.0pre1:
+* PEERINFO:
+ - trust: need *fast* way to check/update trust in peers
+ (async peerinfo would not be right; certainly not with the current API)
+* UTIL:
+ - only connect() sockets that are ready (select()) [Nils]
+ [On W32, we need to select after calling socket before doing connect etc.]
+* 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:
+ - API lacks cancellation methods (needed? or is disconnect enough?)
+ - may also want to integrate request queuing here instead of gnunet-service-fs_drq.c
+* FS: [CG]
+ - support recursive download even if filename is NULL and we hence
+ do not generate files on disk (use temp_filename)
+ - bound parallelism (# fs downloads)
+ - distinguish in performance tracking and event signalling between
+ downloads that are actually running and those that are merely in the queue
+ - persistence support (publish, unindex, search, download)
+ - active migration support (in fs or in datastore or new daemon?)
+ - gnunet-service-fs (hot-path routing, load-based routing, nitpicks)
+ - [gnunet-service-fs.c:208]: member 'LocalGetContext::results_bf_size' is never used
+ - [gnunet-service-fs.c:501]: member 'PendingRequest::used_pids_size' is never used
+ - [gnunet-service-fs.c:654]: member 'ConnectedPeer::last_client_replies' is never used
+ - [gnunet-service-fs.c:669]: member 'ConnectedPeer::avg_delay' is never used
+ - [gnunet-service-fs.c:675]: member 'ConnectedPeer::avg_priority' is never used
+ - [gnunet-service-fs.c:688]: member 'ConnectedPeer::pending_requests' is never used
+ - [gnunet-service-fs.c:694]: member 'ConnectedPeer::last_p2p_replies_woff' is never used
+ - [gnunet-service-fs.c:700]: member 'ConnectedPeer::last_client_replies_woff' is never used
+ - GAP improvements:
+ + active reply route caching design & implementation of service; gap extension!
+* 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
+* GNUNET-GTK:
+ - use g_main_context_set_poll_func to integrate GTK with GNUnet Scheduler!? (YUCK!)
+ - OR: add scheduler API to enable integration with GTK main loop instead of doing our own select
+ - use g_main_context_pending, g_main_context_query / g_main_context_check / g_main_context_dispatch
+ and NEVER g_main_loop_run (can this be done? might be the clean way to do this! But how
+ to integrate this with "gtk_main"? Docu says:
+ "It's OK to use the GLib main loop directly instead of gtk_main(), though it involves
+ slightly more typing. See GMainLoop in the GLib documentation."
+ => so maybe it "just works"?
+* SETUP:
+ - design & implement new setup tool