1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
* 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.
* 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?
* 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
* 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
|
