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
2901287d9e
new 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]*]
2004-06-22 04:50:43 +00:00
2b714967aa
14yyp error
2004-06-22 04:44:17 +00:00
e8734ef1e7
more logging for shutdown info
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)
2004-06-22 04:41:31 +00:00
b1f973d304
during initial router startup, we may try to publish "my.info" before the netDb/ dir is created, so lets make sure
2004-06-22 04:31:25 +00:00
2f17bfd71c
minor 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...
2004-06-22 04:29:28 +00:00
b6670ee23a
lets see how fast this can theoretically go (leaving simulated delays to other components)
2004-06-22 04:26:56 +00:00
f1036df1f6
new debugging data point
2004-06-22 04:25:24 +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
d502df7d56
Make this compile straight out of CVS (you have to have libtomcrypt compiled in a libtomcrypt-0.96 directory in your home directory)
2004-06-21 08:21:17 +00:00
beb6cc8c0f
the journey of a thousand miles begins with a single step :-)
2004-06-21 07:57:11 +00:00
c99db5e75c
change preprocessor conditional to check for 1/0 instead of true/false
2004-06-21 07:50:33 +00:00
65cd70a85b
LibSAM
2004-06-20 11:44:53 +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
2a07ceba62
a 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
2004-06-20 01:49:07 +00:00
3e4b8c7dd4
more stats
2004-06-20 01:45:25 +00:00
26138e213f
new 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)
2004-06-20 01:40:12 +00:00
d82796e3ad
note that we've successfully processed a message (and as such drop its payload) ASAP, and only use safely cached snippets of it afterwards
2004-06-20 01:37:01 +00:00
cdcb81c867
dont be so aggressive about waking up more jobs, since this just causes excess locking when we dont need it
2004-06-20 01:34:16 +00:00
5669e8f060
deal with discarded payloads and use the cached version
2004-06-20 01:31:23 +00:00
d84a40b4dc
add 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
2004-06-20 01:29:00 +00:00
591be43763
default to building more tunnels, because tunnels r k00l
...
(and fix the arg parsing)
2004-06-20 01:26:59 +00:00
97d0686354
new 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)
2004-06-20 01:21:24 +00:00
e2da05b197
more 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
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)
2004-06-20 01:15:01 +00:00
cfc1d1a2db
publish some new stats, including the bandwidth usage (as always, routers can chose not to publish these stats)
2004-06-20 01:12:14 +00:00
9957e6ef17
keep track of how many messages are processed in the tunnel
2004-06-20 01:09:04 +00:00
6a02c8383c
the data is hopefully discarded by now, so dont try to get at it
2004-06-20 01:02:03 +00:00
bc0a4ee68d
discard the data ASAP, and make sure we access only the safely cached snippets of it as necessary
2004-06-20 00:59:33 +00:00
1ca615da77
InNetMessage gets a context
2004-06-20 00:57:02 +00:00
7da0cee29a
turned BandwidthLimiter into an interface, removed some of its teeth, and cleaned up TrivialBandwidthLimiter
2004-06-20 00:56:04 +00:00
f25bccd19f
add some stats for the simulator (data doesnt seem that interesting, so i havent moved them to the CommSystemImpl)
...
use the .discardData() functionality
2004-06-20 00:53:19 +00:00
4e5a2e012c
update since bw limiter interface changed (but dont bother to use it anymore here)
...
i wonder if i should remove the phttp transport now or keep it around in case it gets revived...
2004-06-20 00:50:38 +00:00
c9ee2a92a3
dont buffer the reads, since we dont want that buffer to interfere with either the bandwidth limiting or the AES decryption
...
logging
2004-06-20 00:46:57 +00:00
95a7938328
reduce the max slice time (aka max time to pump out a message + some cleanup) to 60 seconds
...
close connections to peers who are so slow that they leave messages on the queue to expire
reduce the default max queue size per connection to 10 messages
(as always, this is a configurable param, via "i2np.tcp.maxQueuedMessages" in router.config)
2004-06-20 00:44:43 +00:00
baedcdb2c1
handle situations where people dont specify a client name for a client app
2004-06-20 00:40:16 +00:00
bc06b3671a
whenever a tunnel completes, log how many messages we passed through it in the stats:
...
tunnel.inboundMessagesProcessed
tunnel.outboundMessagesProcessed
tunnel.participatingMessagesProcessed
(for the various tunnel types)
2004-06-20 00:35:52 +00:00
a9172811ca
reduce the grace period from 5 to 2 minutes, which will cause us to test peers more often
...
also add some logging (log level == debug will display why we mark a peer as failing)
2004-06-20 00:31:20 +00:00
91b1fd6d07
InNetMessage now needs a reference to a context, so give it one
2004-06-20 00:26:05 +00:00
