1b03e9a3eeWho was the idiot who came up with the idea that booleans should be numbers?
mpc
2004-07-01 09:30:52 +00:00
2b951e3f61Change throws to asserts. If any of this stuff happens it means a code logic error or a retarded computer, so throwing it is just a waste of time.
mpc
2004-07-01 09:17:17 +00:00
d5bd22040cCrappy fix for incorrect Total Bytes Sent/Total Bytes Received via BandwidthLimiter.... ah.. just read the FIXME there. shendaras
shendaras
2004-06-30 13:16:05 +00:00
dcdcb7521adont kill the context, we may need it when tearing down the runner (e.g. to get the time)
jrandom
2004-06-30 04:11:59 +00:00
4058c63884dont be such a prude
jrandom
2004-06-30 03:02:39 +00:00
dd34548cc6publish the tunnel congestion stat
jrandom
2004-06-29 22:32:31 +00:00
a6b5211fa7congestion is only a warning, not an error
jrandom
2004-06-29 22:30:14 +00:00
4e89b9c363reliability threshold = median of active and nonfailing (inactive nonfailing can be a large number of 0 reliability peers)
jrandom
2004-06-29 20:32:36 +00:00
f3e267d2d0active peer testing - every minute, grab two reliable peers, throw a db store at them, and measure their response time the db store sent is their own, and we use tunnels both ways, so they wont know who we are. we also mark the success/failure of the tunnels accordingly
jrandom
2004-06-29 19:45:26 +00:00
2fd87dc1f1when we select peers to test, lets use all of the reliable peers, not just well integrated peers
jrandom
2004-06-29 19:41:30 +00:00
40b6b77cfause the median reliability value of nonfailing peers for the reliabilty threshold, and simplify determining them for the speed and integration
jrandom
2004-06-29 19:40:08 +00:00
d0c61dbf4duse the explicit max ID values (I2NPMessage.MAX_ID_VALUE and TunnelId.MAX_ID_VALUE) logging
jrandom
2004-06-29 19:32:46 +00:00
1cd5a3fcf7include the "addedBy" if we're debugging the job, not if we're debugging JobImpl
jrandom
2004-06-29 19:29:57 +00:00
af81cf2c50explcitly define the max I2NP message ID value and validate against it
jrandom
2004-06-29 19:28:40 +00:00
04373c5d1bjust to be explicit about the max tunnel id
jrandom
2004-06-29 19:25:23 +00:00
caeb2bc4e3the 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
jrandom
2004-06-28 13:21:18 +00:00
13974b601fadded some stats (viewable on the router stat page when the i2ptunnel is run in the router's VM) lots of logging
jrandom
2004-06-28 13:18:18 +00:00
5f0ef5e0e8lets 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
jrandom
2004-06-26 21:13:52 +00:00
1f26c603e0for 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)
jrandom
2004-06-26 21:11:22 +00:00
7e2227ad42lets keep track of how many messages die on our queue due to us being slow
jrandom
2004-06-26 21:07:07 +00:00
9b4899da07always 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
jrandom
2004-06-26 21:05:02 +00:00
a8ad8644c80.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
jrandom
2004-06-25 19:25:33 +00:00
4e91bb88a5workaround 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)
jrandom
2004-06-25 19:21:11 +00:00
784dc0f6a7boot up quicker
jrandom
2004-06-25 18:42:27 +00:00
e80e627fbamore tests with the real TCP transport, not just the VM comm system (and for larger sims, dont keepHistory)
jrandom
2004-06-25 18:41:50 +00:00
d5987c51c9yet 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
jrandom
2004-06-25 18:32:17 +00:00
5ced441b17dont 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.
jrandom
2004-06-25 18:15:32 +00:00
57801202fdflush 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
jrandom
2004-06-25 18:14:12 +00:00
a019399c3creduce synchronization on static (instead use per context objects, for large sims)
jrandom
2004-06-25 17:21:41 +00:00
e6f610a86cdont synchronize on statics, instead use a seperate format object per context (so large sims dont get bogged down on synchronization)
jrandom
2004-06-25 17:20:08 +00:00
7ef528bbdeadd 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
jrandom
2004-06-25 17:18:21 +00:00
a351a29bf3if it expired waiting on the queue for processing, kill 'er
jrandom
2004-06-25 17:12:01 +00:00
085da0cea7Started work on a configuration options object
mpc
2004-06-24 11:47:01 +00:00
5539b19938Added a new example program (which actually works)
mpc
2004-06-23 23:35:39 +00:00
94feb762cakeep detailed info for the sim
jrandom
2004-06-23 19:55:52 +00:00
40b59d5a5amore valid display of bw usage (but not as fresh)
jrandom
2004-06-23 19:54:12 +00:00
9ffd147470handle writing the stats before the period has been reached
jrandom
2004-06-23 19:53:20 +00:00
3fea4ad2bawe dont need to use this fudge in this fashion (its done on the receiving end)
jrandom
2004-06-23 19:51:58 +00:00
1ab5536879la la la (yeah, this is what broke cvs HEAD, causing transmission failures, disconnects, encryption errors, etc. oops)
jrandom
2004-06-23 19:50:41 +00:00
9690a89a6dsliices 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
jrandom
2004-06-23 19:48:25 +00:00
8f895f4349just starting this (backup)
mpc
2004-06-23 12:34:50 +00:00
52fd6ca513Get rid of Debian-specific Makefile -- gcc < 3.0 is obsolete
mpc
2004-06-22 22:49:59 +00:00
eb5dd2ff2eNow it compiles on Cygwin
mpc
2004-06-22 22:48:32 +00:00
7ca35452ebnew 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)
jrandom
2004-06-22 04:56:44 +00:00
551a7ab82fbenchmarking large messages doesnt make much sense when we can compress the payload really really well, now does it?
jrandom
2004-06-22 04:52:06 +00:00
2901287d9enew command line flags to harvest from an explicit file list rather than using all files in a single directory (this lets us specify lots of my.info references to make sure we harvest fresh data, rather than depending upon stat propogation) usage: NetMonitor [configFilename] [--routers filename[,filename]*]
jrandom
2004-06-22 04:50:43 +00:00
e8734ef1e7more logging for shutdown info
jrandom
2004-06-22 04:42:27 +00:00
14b9f9509f* allow the client subsystem to tell the clientMessagePool that a message is definitely remote (since the client subsystem should know). this reduces the churn of the message pool asking all over again * add a new ClientWriterRunner thread (1 per I2CP connection) so that a client application that hangs or otherwise doesn't read from its i2cp socket quickly doesn't hang the whole router (since we've previously used the jobQueue for pushing I2CP messages). This may or may not clear the intermittent eepsite bug, but I'm not counting on it to (yet). * update various points to deal with the client writer's operation (aka doSend won't throw IOException) * logging * lots and lots of metrics (yeah i know some of them vary based on the compiler)
jrandom
2004-06-22 04:41:31 +00:00
b1f973d304during initial router startup, we may try to publish "my.info" before the netDb/ dir is created, so lets make sure
jrandom
2004-06-22 04:31:25 +00:00
2f17bfd71cminor refactoring. i hate how large that method is, but beyond the essential stuff, its pretty much just logging and benchmarking. plus, yeah, this method still takes too long in some situations. working on identifying why...
jrandom
2004-06-22 04:29:28 +00:00
b6670ee23alets see how fast this can theoretically go (leaving simulated delays to other components)
jrandom
2004-06-22 04:26:56 +00:00
f1036df1f6new debugging data point
jrandom
2004-06-22 04:25:24 +00:00
5c3e815757dummy DSA (for sim - dont run on live net)
jrandom
2004-06-22 04:23:19 +00:00
55e780d885logging and doc of a todo (wrt bestEffort)
jrandom
2004-06-22 04:16:17 +00:00
d502df7d56Make this compile straight out of CVS (you have to have libtomcrypt compiled in a libtomcrypt-0.96 directory in your home directory)
mpc
2004-06-21 08:21:17 +00:00
beb6cc8c0fthe journey of a thousand miles begins with a single step :-)
mpc
2004-06-21 07:57:11 +00:00
c99db5e75cchange preprocessor conditional to check for 1/0 instead of true/false
mpc
2004-06-21 07:50:33 +00:00
5166eab5eereplaced 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
jrandom
2004-06-20 04:27:58 +00:00
232f6f158dremoved (likely already ignored by the compiler) op. force of habit from dealing with stream.read() i suppose. thanks mihi
jrandom
2004-06-20 03:48:16 +00:00
2a07ceba62a message send failure is no reason to drop the SAM session for style=stream, tell the client the stream failed, and kill the virtual connection.. for raw and repliable datagrams, just carry on our merry way
jrandom
2004-06-20 01:49:07 +00:00
26138e213fnew method - processingComplete(), which functions much just like OutNetMessage's discardData() so drop the data when called, updating the MessageStateMonitor (and also telling the monitor on finalization, just cuz)
jrandom
2004-06-20 01:40:12 +00:00
d82796e3adnote that we've successfully processed a message (and as such drop its payload) ASAP, and only use safely cached snippets of it afterwards
jrandom
2004-06-20 01:37:01 +00:00
cdcb81c867dont be so aggressive about waking up more jobs, since this just causes excess locking when we dont need it
jrandom
2004-06-20 01:34:16 +00:00
5669e8f060deal with discarded payloads and use the cached version
jrandom
2004-06-20 01:31:23 +00:00
d84a40b4dcadd some randomization to the startup time, so we're not too synchronous also don't shut down so quickly, as the routers may dump some useful stats when they die a horrible death
jrandom
2004-06-20 01:29:00 +00:00
591be43763default to building more tunnels, because tunnels r k00l (and fix the arg parsing)
jrandom
2004-06-20 01:26:59 +00:00
97d0686354new method: discardData() to be called as soon as we dont need the payload of a message anymore (but may still need the associated jobs/etc) check in with the MessageStateMonitor, and cache some key attributes from the message (type, unique id, size, etc)
jrandom
2004-06-20 01:21:24 +00:00
e2da05b197more accurrate (but less lively) bandwidth rate calculation (since we dont necessarily calculate exactly on the edge of a measurement period, we use the data from the last full period) logging on OOM
jrandom
2004-06-20 01:18:31 +00:00
4f0052043d/me waves to our new friend, the MessageStateMonitor, which keeps track of how many messages we're dealing with in memory (and whether they've been processed & discarded yet)
jrandom
2004-06-20 01:15:01 +00:00
cfc1d1a2dbpublish some new stats, including the bandwidth usage (as always, routers can chose not to publish these stats)
jrandom
2004-06-20 01:12:14 +00:00
mpc