fbe9fe1ba8
new method for sanitizing content to be rendered on a web page (specifically, the routerInfo options can be hacked to contain evil html)
...
thanks for finding and suggesting the fix oOo!
2004-08-11 04:42:04 +00:00
cdd74505d7
optional flag to allow using the standard base64 charset on decode/encode, rather than the (filename friendly) i2p charset
2004-08-11 00:59:11 +00:00
7fcc05c037
0.3.4.1, backwards compatible, release later today, blah blah blah
2004-08-08 19:29:53 +00:00
9cccd0bfc9
rather than flush any/all log messages 10 times a second, flush log messages once there are 100 of them or 10 seconds have passed, whichever comes first
2004-08-08 01:40:48 +00:00
8d7786e97d
bad jrandom, test first
2004-08-08 01:34:42 +00:00
2cb519cd06
updated implementation to match the RandomSource javadocs (inclusive of both 0 and n, unlike SecureRandom, which is inclusive of 0 and exclusive of n)
2004-08-07 19:14:13 +00:00
8d8b6da0bf
updated to handle operation without a logger.config (reasonably)
2004-08-01 23:27:37 +00:00
3a61d260d7
cleanup wrt multiple app contexts
2004-08-01 23:24:47 +00:00
96f9618081
expose more data and let the settings be overridden during runtime (and saved to disk)
2004-08-01 05:27:59 +00:00
d10dc1e8d3
Doing something different this time -- but only to core
...
I marked all the empty statements with //nop
I removed unneccessary elses (ie, the if returns or throws)
I took out some casts (integral promotions/some didn't need to be there)
-- Love, shendaras
(2 in one day, w00t)
2004-07-31 01:04:34 +00:00
7f6b477d2e
Fixing up imports (I've been falling down on my job).
...
Note: I didn't touch routerconsole since it isn't done (I believe)
-- Love, shendaras
2004-07-30 22:19:57 +00:00
4467928845
pmd pointed out a few unnecessary things (well, a lot more than just this, but these are the ones i'm fixin ;)
2004-07-30 19:43:59 +00:00
5d4bdc5697
0.3.4 NOT BACKWARDS COMPATIBLE
...
(0.3.4 and not 0.3.3.1 since its got some major revamps)
to be released later today. dont upgrade until the release announcement comes out
2004-07-29 21:37:18 +00:00
c6bb8f09ca
avoid the race that could corrupt local transfers by using a single thread to receive notifications of message availability (and in turn fetch that data)
...
the old way fired off a new (very short lived) thread for each message received, and if two happened really really quickly, they'd both lock on the mutex and the order would be undefined
this avoids that. thanks to oOo et al for pestering me and sending in logs :)
2004-07-29 20:02:12 +00:00
0ed95bbdf1
new helper to read/write
2004-07-27 21:45:56 +00:00
abaa5d87f6
more efficient mem alloc & usage
2004-07-25 23:33:54 +00:00
f170ae741e
0.3.3, backwards compatible, to be released Real Soon
2004-07-24 02:13:37 +00:00
da4827f287
expose some data for the router console to query
2004-07-23 17:39:31 +00:00
9a8a099701
javadoc fix
2004-07-20 21:43:42 +00:00
a5a0c8c837
moved minimal I2CP info to the I2PSession docs (since it is the one that implements it)
2004-07-20 21:31:57 +00:00
d29f9409bf
include some basic I2CP info
2004-07-20 21:16:30 +00:00
b5a0f5910d
first pass
2004-07-20 21:08:04 +00:00
c4e6a2f0a8
if the log pattern/path referenced doesn't exist, create all necessary parent directories (killing the JVM if it fails, rather than silently gobble the log messages to /dev/null)
2004-07-19 17:18:49 +00:00
130399a1e7
0.3.2.3 (coming soon to a hard drive near you)
2004-07-16 21:12:27 +00:00
bbcde2f52b
0.3.2.2 (a lil installation testing and then i'll push)
2004-07-15 01:08:54 +00:00
d6425973e2
include an objectId flag for use in the logging
2004-07-13 20:16:05 +00:00
7b9db07f13
target=1.3 and source=1.3, not target=1.1 and source=1.3
...
(this is what caused the runtime errors on sun jvms but not on kaffe)
((aka i slacked and didn't test sufficiently. off with my head))
this now builds and runs fine in sun 1.3-1.5 jvms, as well as kaffe
2004-07-12 16:39:22 +00:00
0f60ac5acf
0.3.2.1 (backwards compatible blah blah blah)
2004-07-11 18:57:01 +00:00
3bc0e0fc8a
added source and target declarations for the javac commands so we can build with the 1.5^W5.0 JDK
...
(also added deprecation, since, well, we can :)
2004-07-11 04:16:59 +00:00
dd84233085
0.3.2 for release later today
2004-07-07 17:58:37 +00:00
badfb9088e
logging / debugging and formatting (no functional changes)
2004-07-03 19:42:34 +00:00
ff392fee14
properly fake-encrypt the data (this class is only used by the simulator or anything else w/ -Di2p.encryption=off)
2004-07-03 19:41:41 +00:00
aec6e901ee
And I thought I was dyslectic. (duck)
2004-07-02 13:18:00 +00:00
9640e93895
imports
...
shendaras
2004-06-30 13:21:15 +00:00
04373c5d1b
just to be explicit about the max tunnel id
2004-06-29 19:25:23 +00:00
5c1e001a73
logging
2004-06-27 19:39:45 +00:00
a8ad8644c8
0.3.1.5 (backwards compatible)
...
lots of bugfixes. still no rate limiting, but, uh, lots of bugfixes
(release will be packaged and deployed later today)
2004-06-25 19:25:33 +00:00
d5987c51c9
yet another deployment option - the user can define a jbigi.ref environmental variable to specify a file from which the name of the resource to be loaded should be found (default is "jbigi.cfg")
...
if that file exists, the NativeBigInteger will act as if jbigi.impl was set to the contents of that file.
For instance, a jbigi.cfg containing "win-p4" would have the NativeBigInteger search the classpath for the "win-p4" file and use it as a native library.
The jbigi.ref preempts the jbigi.impl property (only if the file exists and is not empty), but the external platform specific jbigi
preempts this (e.g. jbigi.dll or libjbigi.so), as does the jbigi.enable flag.
This option lets us have the admin console write to a file to choose which jbigi to use, rather than have to parse some shell script, etc
2004-06-25 18:32:17 +00:00
dd781e256c
new constructor
2004-06-22 04:53:22 +00:00
5c3e815757
dummy DSA (for sim - dont run on live net)
2004-06-22 04:23:19 +00:00
55e780d885
logging and doc of a todo (wrt bestEffort)
2004-06-22 04:16:17 +00:00
5166eab5ee
replaced double check locking ( http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html ) with the actual logic
...
- prepare the cache prior to use if you want to have the hash cache.
also fix the ejection policy to not clear the cache, but merely to remove sufficient values.
though maybe clearing the cache is the right thing to do so as to avoid ejection churn... hmm.
both of these fixes brought to you by the keen eyes of the one called mihi
2004-06-20 04:27:58 +00:00
232f6f158d
removed (likely already ignored by the compiler) op. force of habit from dealing with stream.read() i suppose.
...
thanks mihi
2004-06-20 03:48:16 +00:00
cc904ba9dc
use new SessionConfig constructor
2004-06-19 23:46:08 +00:00
1679ba6719
so this String.getBytes(), its inefficient? you don't say...
...
(yeah, i know, this optimization takes advantage of the fact that the data in question uses single byte charsets)
2004-06-19 23:41:55 +00:00
07fadd4a6c
avoid string.getBytes like the plague
2004-06-19 23:40:03 +00:00
57e1ff39e0
new method: cachedXor which, suprisingly, determines the xor of a hash against another hash, caching up to a certain number of values
...
currently uses an essentially random ejection policy, but this saves a lot of temporarly memory churn, since we xor many hashes against a router/destination's key
2004-06-19 23:35:43 +00:00
51e259c198
avoiding the String.getBytes() since its a bitch on gc (measured for this situation)
2004-06-19 23:32:41 +00:00
de334b003d
for safety, always create a session config with a destination
2004-06-19 23:30:57 +00:00
a61ff12390
more microoptimizations, whee!
2004-06-19 23:28:12 +00:00
