Commit Graph

298 Commits

Author SHA1 Message Date
a295d0ad1e cleanup the shitlist code
logging
2004-08-15 09:04:56 +00:00
190a2147cc Handle the netDb DoS problem at the root. The DoS was basically old peers telling us about expired
peers that we would crawl the entire netDb looking for (always failing, since there aren't any current
netDb entries for that peer that we would accept).
* keep a shitlist of keys we have recently searched for but were unable to find so we don't flood
* if our in-memory data store won't accept the data, its not helpful, so delete it on disk
* no need to do the preemptive refetching of a leaseSet, since we already garlic wrap it with payloads
* logging
2004-08-15 08:00:28 +00:00
352396bdc2 > Date: Fri, 13 Aug 2004 15:58:30 +1200 (NZST)
> Message-ID: <1776.202.37.75.101.1092369510.squirrel@202.37.75.101>
> From: adam@adambuckley.net
> To: jrandom@i2p.net
>
> [...]
>
> I hereby authorize my NtpClient.java and NtpMessage.java code to be
> redistributed under the BSD license for the purpose of integration with
> the I2P project, providing that I am credited as the original author of
> the code.
>
> [...]
w00t!  adam++
code migrated into core/java/src/net/i2p/time, integrated with Clock,
dropping that whole ugly pass-the-time-through-URL, and hence dropped
support for :7655/setTime.
New router.config properties to control the timestamper:
  time.sntpServerList=pool.ntp.org,pool.ntp.org,pool.ntp.org
  time.queryFrequencyMs=300000
  time.disabled=false
So, to disable, add time.disabled=true to your router.config.  It is
enabled by default.
Default router.config and startup scripts updated accordingly (since
timestamper.jar is now gone)
2004-08-13 21:15:22 +00:00
3c9b0273d4 only count locally generated lookup messages for detecting local DoS (duh) 2004-08-13 02:52:17 +00:00
8ebd22da96 hmm i thought i already committed this. well, anyway, cleaner stats wrt searching 2004-08-13 02:21:18 +00:00
c2d55013a6 0.3.4.2, backwards compatible, release pretty soon 2004-08-13 02:15:54 +00:00
25eda1378e * do DoS detection in constructor, so we get useful "why are we doing this"
stack traces (rather than "oh, we're doing it when... uh... writing to the socket")
* increase the throttle max, since we want to be able to send a few concurrent
2004-08-13 02:11:54 +00:00
dfac7bde9c * track searches more carefully
* detect situations where we may be inadvertantly flooding the netDb
and log them as CRIT with a stacktrace, as well as publish the count
of those events in the netDb
* detect potential netDb DoS situations by checking to see if we have
received more than 20 netDb lookups in 10 seconds, and if so,
probabalistically drop subsequent netDb messages (P=1-(10/numReceived)).
This is also published in the netDb.
2004-08-13 01:43:01 +00:00
348168d6c0 made the log less verbose for duck ;) 2004-08-13 01:27:55 +00:00
f1ce1b5361 if we reach this point, bump up the expiration if necessary (otherwise the fast expire will occur with small clock skews) 2004-08-12 03:24:44 +00:00
ebdc7d70a1 shitlist appropriately (continued) 2004-08-12 03:23:48 +00:00
eeb1852d95 take note of the reason each peer is shitlisted and display that on the console (good idea oOo)
cleaned up the shitlisting process within the TCPTransport so that we don't shitlist twice (clobbering the detailed cause with a general "uh, couldn't contact 'em" cause)
2004-08-11 22:51:00 +00:00
d524c77560 *cough* (oops) 2004-08-11 08:23:56 +00:00
0025d94aa4 if the message has expired but hasn't exceeded the fudge factor, we still need to give it some time to be processed (we receive and validate it first, and if it reaches these jobs, we should let it continue)
logging
2004-08-11 07:10:37 +00:00
fbe9fe1ba8 new method for sanitizing content to be rendered on a web page (specifically, the routerInfo options can be hacked to contain evil html)
thanks for finding and suggesting the fix oOo!
2004-08-11 04:42:04 +00:00
0aa023189d shitlist the old idents of peers who change idents
be sure to fire any onFail jobs if we aren't going to pass a message off (duh)
take clock skew into account when determining whether a message is expired (duh^2)
2004-08-11 00:57:36 +00:00
b89e26c460 cleaned up the validation of leaseSet/routerInfo elements being accepted so we validate only in one place (in the facade instead of both the facade and the dataStore)
don't accept entries created (too far) in the future
2004-08-10 16:55:54 +00:00
97e5952544 another oOo catch (not sure if this is ever run - it shouldn't be, but now it'll display the silly statement more clearly :) 2004-08-10 04:52:48 +00:00
8627328047 set the nextHopId whenever we know the nextHopInfo (duh) [thanks oOo!]
this should fix the deserialization errors from tunnels.dat
2004-08-10 04:11:58 +00:00
ec0c912c6f oOo's updates:
* properly describe expired leaseSets (e.g. "30s ago" instead of "in -30s")
* add a little table at the end of the netDb HTML summarizing the versions people claim to be running
2004-08-10 01:07:33 +00:00
7fcc05c037 0.3.4.1, backwards compatible, release later today, blah blah blah 2004-08-08 19:29:53 +00:00
edf17d0a46 drop the arbitrary wait during creation (but not during startup)
only relevent to simulations, obviously
2004-08-08 19:26:44 +00:00
e57c010e3d reduced context switches by removing the timeout val that was redundant 2004-08-08 01:39:00 +00:00
c0f32c942d more checking for timeout 2004-08-06 22:23:00 +00:00
4859cd7dcf new job to aggressively fetch the most up to date routerInfo from peers by, er, asking them for it
disabled by default (enable through router.config 'netDb.shouldHarvest=true').
useful if you want to harvest the published router stats, since otherwise you could have data from a few hours back
2004-08-05 02:58:13 +00:00
d44d8cc53d penalize peers whose tunnels probably fail, but still dont kill those tunnels quite yet
logging
2004-08-01 20:41:33 +00:00
1305969247 requeues aren't absurd in a live net where connectivity sometimes fails (duh) 2004-08-01 20:39:17 +00:00
94becebafa increase the (essentially) arbitrary choke on message send times (which has caused some reliability problems under load) 2004-08-01 20:37:44 +00:00
34f119ca23 moved the router config reading code into the, er, router 2004-07-31 23:25:02 +00:00
09ed1b1f9e logging 2004-07-31 23:22:38 +00:00
a05e8a446d update the default tunnel settings dynamically (adjusting the pool size accordingly) 2004-07-31 04:16:30 +00:00
21126f766c put the adminManager in the context so we can control it (and in turn, restart it) 2004-07-31 04:15:09 +00:00
a6993fa489 now allow restarting within the same jvm (loading all the config options again, rebinding sockets, etc - it does NOT fire up all the clientApp tasks though - those aren't part of the router) 2004-07-31 02:21:46 +00:00
7f6b477d2e Fixing up imports (I've been falling down on my job).
Note:  I didn't touch routerconsole since it isn't done (I believe)
-- Love, shendaras
2004-07-30 22:19:57 +00:00
fd2a4029e7 html cleanup for the new console 2004-07-30 20:27:13 +00:00
5d4bdc5697 0.3.4 NOT BACKWARDS COMPATIBLE
(0.3.4 and not 0.3.3.1 since its got some major revamps)
to be released later today.  dont upgrade until the release announcement comes out
2004-07-29 21:37:18 +00:00
25378e894b less aggressive removal of peer references
logging
2004-07-29 20:36:44 +00:00
c02522b0fe * track the message progress through the send process more carefully
* drop the outbound message as soon as it expires rather than transferring an expired message
* drop hard any outbound message that takes us over 5 seconds to process (if we have a 5s message processing time, we do no one any good)
* don't try to resend (only useful when dealing with multiple transports - aka insufficiently tested code)
* don't republish netDb messages as often
2004-07-29 05:37:10 +00:00
c2a71ef756 include stats on bytes wasted (overflow from the buckets) 2004-07-28 23:35:48 +00:00
e669110cf4 be sure to allow for clock skew 2004-07-28 23:34:42 +00:00
f4cf31c13d less aggressive passive publishing 2004-07-28 23:34:02 +00:00
7b23a5dcce keep track of wasted bytes (overflow from the bucket) 2004-07-28 23:32:51 +00:00
b2fda0c79d catch errors earlier 2004-07-28 23:29:21 +00:00
5af96f5ccb when we really need tunnels, always build them 2004-07-28 23:28:55 +00:00
ca445ac178 when we need tunnels, always build 2, not the exact quantity required (so that its a bit smoother) 2004-07-28 23:27:46 +00:00
5eaec4c841 only recurse one time 2004-07-28 03:51:38 +00:00
ffcc34c4f9 heh, if it expires, we probably don't want to forward it (duh) 2004-07-28 03:50:30 +00:00
2dbe33e769 * cleaned up the tunnelCreate reply timeout
* reduced the number of tags passed when garlic routing a tunnelCreate
* catch timeout on a tunnel message quicker
* give a tunnel message a new messageId per hop
* added some more infrastructure for per-hop tunnelId
2004-07-28 00:08:15 +00:00
60c7db0733 if I'm making this backwards incompatible, I might as well clean up the rest, 'eh?
* removed SourceRouteBlock & SourceRouteReplyMessage, as they're a redundant concept
that 1) takes up bandwidth 2) takes up CPU 3) smell funny.
now the TunnelCreateMessage includes a replyTag, replyKey, replyTunnel, and
replyGateway that they garlic encrypt their ACK/NACK through and with.

* tunnelCreateMessage doesn't need a seperate ACK - either we get a
TunnelCreateStatusMessage back or we don't.

* message structure mods for unique tunnel ID per hop (though currently all hops have
the same tunnel ID)
2004-07-27 22:04:02 +00:00
c901bcf9b7 javadoc warning fix 2004-07-27 17:41:40 +00:00