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
bab7b8b9ed
discard the payload of a message ASAP (even though we may need to hang on to the message for a while, for its replyJob, etc)
...
take note of the fact that the tunnel had activity
minor logging and formatting updates
2004-06-20 00:24:06 +00:00
1b7fb96ca8
dont expose a method we dont need to expose
2004-06-20 00:19:38 +00:00
6d84b8c02f
1) use cachedXor to cut down on the, uh, xor-ing (which involves at least one new byte[32])
...
2) implement an optimized 'should contain' algorithm, rather than being a wuss and building + comparing a BigInteger of the xor.
3) more unit tests
this stuff is called a *lot*, since we need to pick what bucket things go in all the time.
2004-06-20 00:18:28 +00:00
3e3749f011
added some unit tests (adding the local key (delta == 0x00) and adding 1000 random keys, all making sure nothing b0rks)
2004-06-20 00:13:05 +00:00
52384fb3a5
persist the local router's info @ netDb/my.info in addition to under netDb/routerInfo-$hash.dat
...
this makes it easy for harvesting with simulations
2004-06-20 00:11:23 +00:00
e401670087
i like logging, dont you like logging?
2004-06-20 00:08:59 +00:00
ae0b4c59cc
include the port # in the thread name, and logging
2004-06-20 00:07:37 +00:00
0a8dc8afcc
logging, its whats for dinner
2004-06-20 00:06:33 +00:00
d59b94df66
logging, deal with times when a client doesnt have a destination yet
2004-06-20 00:05:30 +00:00
e28502454b
include the port in the thread name (useful for the sim)
2004-06-20 00:03:45 +00:00
bbf73f0937
enforce some sanity checks on the payload size. see recent rant in DatabaseSearchReplyMessage commit for why
...
this is necessary.
2004-06-19 23:58:24 +00:00
592519c45c
somehow some people are getting situations where the payload doesnt decompress. wtf?
...
do i need to wrap the Input/Output streams we use to pipe data over the net with a verification wrapper for the messages?
e.g. prefix the serialization of all I2NPMessages sent on the wire with the SHA256 of that serialization and verify on read?
Ho hum, dunno. maybe its something else, but the ElG/AES+SessionTag already has integrity verification so the only thing I can
think of is a checksum error that got past TCP's checking and corrupted the AES stream.
2004-06-19 23:56:41 +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
f4697be159
just a simple catch all for OOM while handling an OOM (naw, we dont recurse too much (just a little))
2004-06-19 23:25:47 +00:00
3835fe3960
give the shutdown hook thread a name
2004-06-19 23:13:09 +00:00
76c374ef06
more accurate memory usage to reduce gc churn
2004-06-19 23:11:42 +00:00
57d24bd948
read the logger.config when its been updated, even if we dont have any log messages to write out (duh)
...
also, a micro-optimization for charset handling identified through profiling
2004-06-19 23:02:59 +00:00
deff14dfd8
lets see if this fixes bug 66 ( http://dev.i2p.net/bugzilla/show_bug.cgi?id=66 )
2004-06-13 20:27:44 +00:00
0a479be370
include NAME=val in failed lookup replies (per spec - thanks nightblade)
...
fixes http://dev.i2p.net/bugzilla/show_bug.cgi?id=79
2004-06-13 20:19:16 +00:00
ba6a2e3fd2
unit test for the bandwidth limiting functionality (TrivialBandwidthLimiter, BandwidthLimiter, BandwidthLimited{In,Out}putStream)
2004-06-13 20:03:21 +00:00
c3a395a41e
update the bandwidth limiter config properties
2004-06-13 19:59:44 +00:00
a3136a19e9
big ol' rewrite, requiring new config settings and, er, it works pretty well.
...
see router.config.template mods and the new unit tests.
this implementation can cause starvation -
e.g. lots of 1KB writes will go through before a 32KB write if the queue is low and the bwlimiter only replenishes say, 16KBps
another impl would enforce a FIFO through thread wait/notify, etc, but would have the related overhead.
i dont know whether starvation situations will be the norm or the exception. i'm running this on a few routers so we'll see.
2004-06-13 19:56:57 +00:00
b631568003
deal with null routers
2004-06-13 19:48:23 +00:00
1d0c03eca4
use the router context's properties (which now include the config settings)
2004-06-13 19:47:44 +00:00
eb30525a26
deal with null routers (useful for testing)
2004-06-13 19:47:02 +00:00
3e66ea3f56
include the router's config in the property settings
2004-06-13 19:45:53 +00:00
9f1189e606
use a bandwidth limited stream instead of asking for the allocation of the entire buffer at once (since, uh, its not likely that the bandwidth limiter will ever have hundreds of KBytes available for use)
2004-06-13 19:39:42 +00:00
698927bed4
logging
2004-06-13 19:37:18 +00:00
8fd02ee8dd
allow the stream to optionally pull from the output stream's bandwidth limit queue (useful in very strange situations)
2004-06-13 19:36:41 +00:00
f3154e8f5e
buffer between the bandwidth limiter and the raw stream
2004-06-13 19:34:46 +00:00
878af163a9
handle null boolean value (legal, but not in this context), fixes bug reported by nickster
2004-06-13 19:32:58 +00:00
