caeb2bc4e3
the actual fix for the local eepsite problem (if getRemoteID was called *after* the remoteID was set, it would wait for 60s then fail. now we check for that)
...
synchronization cleanup (never get two locks)
logging
2004-06-28 13:21:18 +00:00
13974b601f
added some stats (viewable on the router stat page when the i2ptunnel is run in the router's VM)
...
lots of logging
2004-06-28 13:18:18 +00:00
cbc6aea8b4
logging
2004-06-27 21:20:31 +00:00
290a2f7ccd
(ok this is a little silly)
2004-06-27 21:08:19 +00:00
349e80f206
allow sending ASAP and remove any artificial delays
2004-06-27 20:53:32 +00:00
5c1e001a73
logging
2004-06-27 19:39:45 +00:00
f312318fab
Finished winsock code cleanup
2004-06-27 13:07:06 +00:00
dc04b7cf09
Some winsock improvements
2004-06-27 09:12:05 +00:00
77a8a46d8e
lets try to reduce creating new objects during finalization
2004-06-26 21:15:51 +00:00
95c7cd55c2
logging
2004-06-26 21:15:16 +00:00
5f0ef5e0e8
lets not crap on the secondary tunnel too (even though doing so isn't wrong)
...
this helps avoid catastrophic failures, at least a little, since a failure doesnt kill two sets of tunnels
2004-06-26 21:13:52 +00:00
1f26c603e0
for now, lets disable the tunnel pool persistance. this means that after a router crashes, tunnels it was participating in will fail even if the router comes back up before they expire.
...
disabling this saves us some IO contention (though this may only be relevent on my kaffe box... dunno)
2004-06-26 21:11:22 +00:00
7e2227ad42
lets keep track of how many messages die on our queue due to us being slow
2004-06-26 21:07:07 +00:00
9b4899da07
always use the cached host/port rather than grabbing the socket's InetAddress (in case it disconnects and throws NPEs)
...
use the NativeBigInteger as part of the session key negotiation (oops, forgot this one last time)
logging
2004-06-26 21:05:02 +00:00
83c88ac0c6
minor fixes
2004-06-26 02:26:37 +00:00
44623065b4
Threads (untested)
2004-06-26 02:16:54 +00:00
47c7c8177d
Mutex code (untested)
2004-06-25 22:22:48 +00:00
bde7a5ff59
Mutex code (untested)
2004-06-25 22:19:18 +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)
i2p_0_3_1_5
2004-06-25 19:25:33 +00:00
4e91bb88a5
workaround an aggressively up-to-spec kaffe implementation (the spec says Socket.getInetAddress() is null if not connected,
...
but sun lets the getInetAddress() return a value if it had connected then disconnected, while kaffe buggers off and NPEs)
2004-06-25 19:21:11 +00:00
f60a90e2da
added forum.i2p
2004-06-25 18:48:33 +00:00
784dc0f6a7
boot up quicker
2004-06-25 18:42:27 +00:00
e80e627fba
more tests with the real TCP transport, not just the VM comm system (and for larger sims, dont keepHistory)
2004-06-25 18:41:50 +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
5ced441b17
dont fail the peer based on tunnel activity (it may not be their fault)
...
we *do* still penalize the peer based on tunnel failures, but thats in the reliability calculator, not this one.
2004-06-25 18:15:32 +00:00
57801202fd
flush the protocol flag explicitly
...
make the tcp connection handler nonblocking by adding another (very short lived) thread - this prevents a peer connecting to us that is very slow (or unconnectable) from forcing other cons to timeout
completely ripped out the fscking bandwidth limiter until i get it more reliable
gave threads more explicit names (for the sim)
logging
2004-06-25 18:14:12 +00:00
a019399c3c
reduce synchronization on static (instead use per context objects, for large sims)
2004-06-25 17:21:41 +00:00
e6f610a86c
dont synchronize on statics, instead use a seperate format object per context (so large sims dont get bogged down on synchronization)
2004-06-25 17:20:08 +00:00
7ef528bbde
add some minimal security to the admin console, requiring a passphrase to be entered when updating the clock offset
...
this works by a simple substring match of the URL - if the router.config contains the adminTimePassphrase=blah, the time update will only succeed if the URL contains "blah" in it
if the router.config does NOT contain an adminTimePassphrase, the time update WILL BE REFUSED.
aka to use the timestamper, you MUST set adminTimePassphrase AND update the clientApp.0.args= line to include the passphrase in the URL!
e.g.
clientApp.0.args=http://localhost:7655/setTime?blah pool.ntp.org pool.ntp.org pool.ntp.org
2004-06-25 17:18:21 +00:00
a351a29bf3
if it expired waiting on the queue for processing, kill 'er
2004-06-25 17:12:01 +00:00
983d258bce
logging
2004-06-25 17:09:55 +00:00
f6d38dd5e0
reduce SimpleDateFormat usage (implicit in Date.toString())
2004-06-25 17:03:13 +00:00
d51245aada
logging
2004-06-25 17:02:22 +00:00
56cf51f0f9
New configuration system
2004-06-25 01:31:02 +00:00
eb40fb9c5d
typo
2004-06-24 11:51:24 +00:00
085da0cea7
Started work on a configuration options object
2004-06-24 11:47:01 +00:00
5539b19938
Added a new example program (which actually works)
2004-06-23 23:35:39 +00:00
94feb762ca
keep detailed info for the sim
2004-06-23 19:55:52 +00:00
40b59d5a5a
more valid display of bw usage (but not as fresh)
2004-06-23 19:54:12 +00:00
9ffd147470
handle writing the stats before the period has been reached
2004-06-23 19:53:20 +00:00
3fea4ad2ba
we dont need to use this fudge in this fashion (its done on the receiving end)
2004-06-23 19:51:58 +00:00
1ab5536879
la la la
...
(yeah, this is what broke cvs HEAD, causing transmission failures, disconnects, encryption errors, etc. oops)
2004-06-23 19:50:41 +00:00
9690a89a6d
sliices are only too slow if there's something pending
...
logging mods
i really need to rewrite the tcp transport - the code is all functional, but the design sucks.
with the FIFO bandwidth limiter we could get away with a single 'send' thread rather than each TCPConnection having its own writer thread (but we'd still need the per-con reader thread, at least until nio is solid enough)
but maybe the rewrite can hold off until the AMOC implementation. we'll see
2004-06-23 19:48:25 +00:00
8f895f4349
just starting this (backup)
2004-06-23 12:34:50 +00:00
980c0aa1d7
Added PRNG code
2004-06-23 11:56:53 +00:00
52fd6ca513
Get rid of Debian-specific Makefile -- gcc < 3.0 is obsolete
2004-06-22 22:49:59 +00:00
eb5dd2ff2e
Now it compiles on Cygwin
2004-06-22 22:48:32 +00:00
7ca35452eb
new target - buildclean (== distclean build)
...
useful for my ide so i dont have to run two targets sequentially (and 'dist' goes one step further to include javadoc, which i dont need)
2004-06-22 04:56:44 +00:00
dd781e256c
new constructor
2004-06-22 04:53:22 +00:00
551a7ab82f
benchmarking large messages doesnt make much sense when we can compress the payload really really well, now does it?
2004-06-22 04:52:06 +00:00