Commit Graph

658 Commits

Author SHA1 Message Date
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
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
ba6a2e3fd2 unit test for the bandwidth limiting functionality (TrivialBandwidthLimiter, BandwidthLimiter, BandwidthLimited{In,Out}putStream) 2004-06-13 20:03:21 +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
ca6884dbca imports (sorry, includes alphabetizing, wee)
(shendaras)
2004-05-24 03:21:21 +00:00
1ebb0ac5fb 0.3.1.4 (backwards compatible)
i'll package & push later this evening
2004-05-23 16:54:29 +00:00
bf0e53f13b i'll swallow your soul!
er... make it queue up to 20 messages (in case of bursts), and do some more verbose logging
2004-05-23 16:52:56 +00:00
04be41aac5 if the send queue to the peer is too large, fail the message but also mark it as a comm error (since either their net con is insanely saturated, or disconnected)
logging
2004-05-22 12:05:34 +00:00
fd1313d49f bugger the speed estimate - always use the measured values, and if there aren't enough measured values, use 0. 2004-05-22 12:03:38 +00:00
3599dba5c3 javadoc 2004-05-22 12:02:51 +00:00
67edc437d2 properly !LART on comm error, and initialize the log correctly 2004-05-22 12:02:18 +00:00
7a39d9240c logging 2004-05-22 12:00:08 +00:00
ddb6348bfd type safety? we dont need no stinkin' type safety!
(aka expiration vs timeoutMs, as shown by tunnel test messages that don't expire for another 30 years)
this'll leak memory for failed tunnels, so we'll push this in a new rev in the next day or two, or maybe later today if it gets really bad.
2004-05-20 13:43:09 +00:00
d70c5df5a0 0.3.1.3 (not backwards compatible, yadda yadda yadda) 2004-05-20 11:32:32 +00:00
f2fa2038b1 * made dbStore use a pessimistic algorithm - requiring confirmation of a store, rather than optimistically considering all store messages successful (NOT BACKWARDS COMPATIBLE)
* when allocating tunnels for a client, make sure it has a good amount of time left in it (using default values, this means at least 7.5 minutes)
* allow overriding the profile organizer's thresholds so as to enforce a minimum number of fast and reliable peers, allowing a base level of tunnel diversification.  this is done through the "profileOrganizer.minFastPeers" router.config / context property (default minimum = 4 fast and reliable peers)
* don't be so harsh with the isFailing calculator regarding db lookup responses, since we've decreased the timeout.  however, include "participated in a failed tunnel" as part of the criteria
* more logging than god
* for dropped messages, if it is a DeliveryStatusMessage its not an error, its just lag / congestion (keep the average delay as the new stat "inNetPool.droppedDeliveryStatusDelay")
2004-05-20 11:06:25 +00:00
bfd59e64ea refactored the cleanup job
logging
2004-05-20 10:53:31 +00:00
60e05e270a cleaned up slice processing
reduced max queued messages per connection to 10 (additional ones are immediately marked as failed)
update the I2P_FLAG byte to '*' making this NOT BACKWARDS COMPATIBLE
formatting
2004-05-20 10:51:22 +00:00
0e5d164a8a support shutting down the router from the web console:
specify a "router.shutdownPassword" value in the router.config (or in the environment [ala -D]),
  then specify that password on the shutdown form in the web console and hit submit.  after 30 seconds, it'll kill the router (and unless you're running the sim, it'll kill the JVM too, including clientApp.* started tunnels / etc)
if we had some sort of ACL for accessing the web console, we could avoid the password field altogether, but we dont, so we cant.
2004-05-19 22:00:32 +00:00
7243963106 removed the insane explicit GC 2004-05-18 18:39:43 +00:00