path: root/ISSUES

* I'm currently confused about the statistics API bug (from C), and how shutdown/disconnect is/should be handled.
* gnunet vs GNUnet, gnunet-java project name
* I'm currently trying to increase the robustness of the service APIs,
  discuss behavior in some cases
* packaging requirements


====================================================================

* IzPack is ~15MB, do we really want to have it in the svn repo?
No, env var.

* the Runabout can now be an anonymous inner class
 * implementation overhead: for public subclasses only constant overhead in the Runabout constructor
 * for private/anonymous inner classes: 10-20% overhead, measured over 100M calls
 * only issue left: visit methods have to be public, but this is a non issue.

* review the RequestQueue mechanism

* Statistics:
 * currently watches can't be canceled on the service level, only on the api level, is this intentional?
=> fine for now

* DHT:
 * getStart timeout does not really make sense (why timeout for transmission to the service,
   but not for retrieval of answers?)
   Is this just a documentation error?
=> fine to NOT have the timeout argument in the Java API

* core:
 * what happens if during a transmission the service disconnects? should we retry?
=> "no"

* with the changes in ARM there is no way to restart gnunet with arm if some client is misbehaving
=> SVN UP

* I'm often getting
  May 09 09:21:49-194786 util-11121 WARNING `socket' failed at connection.c:892 with error: Too many open files
=> SVN UP


==================

#!bin/sh
java -jar $GNUNET_JAVA_PREFIX/lib/gnunet.jar


==================

#!/bin/sh
if test -z $GNUNET_JAVA_PREFIX
then
  GNUNET_JAVA_PREFIX=%INSTALL_PREFIX%
fi
java -jar $GNUNET_JAVA_PREFIX/lib/gnunet.jar



===========================================================

* @UNIXONLY@ PORT = 2089 in src/util/resolver.conf.on
 * what's the purpose? we also need this line to be enabled on JAVAPORT

* something I didn't think through from the beginning:
  how should unknown message types be handled by message handlers?
 * sometimes we want to see the message (e.g. in server), sometimes it is an error
 * alternative 1: signal an error to the message handler, somehow pass the original message
 * alternative 2: pass a special UnknownMessage to the message handler, filter it for higher-level
   APIs and signal an error.


* the recvDone is kind of clunky (see test/org.gnunet.util.ServerExample)

* finally core/statistics/dht/resolver/... have unit tests!
  (and coverage works again, but i can't access the cobertura via ssh yet)
 * currently most test rely on a running gnunet, and use the default configuration
 * alternative approach:
  * configuration is copied from resource (may be in a jar!) to a temp file, then passed on the command
    line to gunet-service-*
  * useful to test behavior on disconnects
  * problem: java sucks at managing processes, processes stay alive if we abort a test
 * dht get: can we assume that "our" peer immediately stores the value?

* naming: when do we use destroy, when do we use disconnect, or is this arbitrary?
  start-stop, create-destroy, connect-disconnect; constructor: fine, destructor: see C API

* implications of using exceptions in callbacks
 * esp. when the exception is non-fatal, i.e. the exception is caught, handled, and the program continues
 * java exceptions have no restarts, may leave gnunet-java in inconsistent state; FINALLY!

* how to test callbacks? we do not only need to test for the right values, but also check that callback has actually
  been called.
 * first approach: thow a TestSuccess exception, discarded (see above)
 * current approach: build a list of assertions, check assertions after scheduler is done.
  * each assertion stores whether it already succeeded and a message


* finalziers: used to destroy object. lead to heisenbug/double disconnect. now policy: check if object
  has been disposed of properly, otherwise log a warning.
 * cannot guarantee cleanup anyway
   (java behavior: run finalizers iff unreachabla during gc, may never happen, finalizers on jvm shutdown deprecated)


* regarding peerinfo
  * i don't fully understand how HELLOs work.

* what are the next important services to implement? (probably mesh, peerinfo, transport)


* i'm currently considering to use the google guava library
 * Apache License 2.0
 * con: large (1.8MB jar)
  * but: unused class files could be stripped from the jar, e.g. using ProGuard
 * would replace the apache commons io library
 * contains collections used throughout gnunet
  * bloomfilter
  * multimap, alleviates the boilerplate code when dealing with hashmaps of lists
 * methods to deal with "signed" primitives
 * dealing with files (e.g. copying)
 * redirecting i/o streams from/to files (when issuing external commands)
 * hashing utilities
 * tables (mapping from key pair to value), would replace nested Maps in e.g. Configurations
 * ...




* long-term todos:
 * refactor the Construct implementation, implement the "nicer" syntax
 * refactor the getopt implementation




============================================================

* tests now run on the cobertura account :)
 * see https://gnunet.org/cobertura/
 * gnunet needs to compiled with --disable-nls to work on the server
 * cronjob added
 * could/should we report the success of JUnit tests?
  * (as somehow my bugs only seem to show when running on another system ;)

* gnunet-java now can now start/restart services for testing with the testing wrapper executable
 * i duplicated the code for GNUNET_TESTING_service_run_restartable
  * now passes the Peer to main, which can start/stop it
  * probably also should pass the config file name (not only the handle)
   * how about a GNUNET_TESTING_peer_get_config_path?
 * what about windows?

* server/service:
 * needed for testing the server: getting an unused port with java
 * how do we test the signal pipeline?
  * probably with runin arm in a testing peer, but then we would also have to talk to arm


the following notes are old:
* we are still not able to test "temporary destruction"
 * because every time a new port may be generated
 * we need a way to kill a service and run it with the same config
 * now implemented!
* review if everything in Makefile.am is correct
 * what is *_DEPENDENCIES vs *_LDADD?
* how do we get a handle to stdin (in a non-hacky way) that can be selected on by scheduler?
* c-getopt question: GNUNET_GETOPT_run returns index of first non-option.
  so options and non-options may not be mixed?
* i have to manually write the config file, why isn't there a way to get the
  file name, not just the ConfigurationHandle?
* could we get a confirmation that a service *really* is dead?
 * or is this guaranteed if TESTING_service_run returns?
 * otherwise there is no way to reliably test behavior on interrupted connection
* TESTING_service_run does not indicate that the service could not be run!
 * just logs an error
 * currently we check availability of data on stderr.


PEERINFO_GET vs PEERINFO_GET_ALL
 * if we have PEERINFO_GET_ALL, why is the peer-field in ListPeerMessage(with type=PEERINFO_GET) empty?


* are peerinfo requests queued?
 * i remember discussing peerinfo as a compilicated example for a general message queueing implementation. why?
 * if we have to queue: how about a "choke/release" for the outgoing message queue?
  * otherwise we don't know which requests belongs to which response
* can peerinfo return more than one record per peer?


--------------------------------------------------------------

* see mantis for problem with the signal pipe

* what should the gnunet-testing-run-server tool be called, now that
  there already is plain gnunet-testing?

* where should TESTMessage and HELLOMessage, PeerIdentity, HashCode go?
 * and do we want to call them TESTMessage or TestMessage?

* had a bug in the IPv6 address parsing code
 * tried to fix it / rewrite it, eventually got frustrating
 * found out guava has an implementation of this :)
  * also implements shortening (like ::1)
  * by reading the code: implementing all this correctly would not have been a fun time

* TestingServer now allows the client/connection/server to be tested easily
 * found quite some bugs during this

* thoughts about exponential backoff / the client-connection stuff in GNUnet and gnunet-java
 * why do we wait the entire backoff period, if the connection could be available earlier?

* discuss what mesh does, what transport does
 * i found the documentation for transport on gnunet.org
 * the is not much information about mesh, except for the source code

---------------------------------------------------------------

* reference count / receive_done behavior is a bit strange / confusing
 * clients are disconnected only when refcnt==0 *and* shutdown is requested?
 * behavior on receive done: when success=1 but refcnt=0, why don't we disconnect the client?

   /**
    * Was processing if incoming messages suspended while
    * we were still processing data already received?
    * This is a counter saying how often processing was
    * suspended (once per handler invoked).
    */

I don't understand that comment!



* im currently confused about the different layers of GNUnet / I don't get the big picture
 * e.g. transport's distance vector plugin vs mesh
 * peerinfo / mesh
 * assuming a large network, doesn't a client have to store a large amout of information?

* how to test MESH?
 * maybe talk to Harsha about testbed? :)

* interesting things happen with JUnit
 * failure of one test causes timeout in another

* review org.gnunet.testing

cp a x ; cp b x
is not the same as
cp b x ; cp a x
if x does not exist prior to copying