jrandom
ff392fee14
properly fake-encrypt the data (this class is only used by the simulator or anything else w/ -Di2p.encryption=off)
2004-07-03 19:41:41 +00:00
mpc
a13693161a
http://www.kirstenfan.com/galleries/magazines/fhm2002100sexy/002.jpg -- studies show charming women love computer programmers......
2004-07-03 11:05:23 +00:00
jrandom
4b8ac81669
minor refactoring, javadoc
...
dont add an arbitrary extra Router.CLOCK_FUDGE_FACTOR to the expiration
2004-07-02 18:57:42 +00:00
jrandom
219a704ee0
bugger it, for consistency, always include the reply leaseSet with a message (later, when we want to optimize the bandwidth requirements, we can revisit)
2004-07-02 16:59:37 +00:00
jrandom
3996cd1f08
make the client writer thread run at max priority, since it is very time sensitive and only executes for very brief periods
2004-07-02 16:53:49 +00:00
jrandom
c636b0a0ec
minor rewrite to make timing more precise (keeping a map of message add times, not just the 'last' add time)
2004-07-02 15:12:35 +00:00
duck
aae9f671f0
added jdot.i2p (duck)
2004-07-02 13:31:09 +00:00
duck
aec6e901ee
And I thought I was dyslectic. (duck)
2004-07-02 13:18:00 +00:00
mpc
f49be25288
<Nightblade> hmm
2004-07-02 09:54:27 +00:00
mpc
f9a96126e1
I don't know how I missed this stuff before
2004-07-02 09:37:54 +00:00
shendaras
8c9f58b939
Misc. stuff: javadoc, UNUSED...
...
shendaras
2004-07-02 02:54:04 +00:00
jrandom
8a7e787f42
logging
2004-07-01 22:33:51 +00:00
jrandom
148dcc084d
factor out the clientWriterRunner and have it deal with multiple i2cp messages being enqueued really fast (at least, more efficiently, by pulling them all off at once and handling them in one pass)
2004-07-01 15:21:32 +00:00
jrandom
15b1cbd762
synchronize the available() call, and made explicit some other synchronization
2004-07-01 15:11:34 +00:00
jrandom
e9b7ca3697
dont accept outrageously long delays when building a tunnel (aka now each peer only gets the timeout to respond, instead of the full # peers * timeout to respond)
...
this will cause more dropped messages to show up, but in turn it will avoid slower peers (since they'll be marked down as rejecting the tunnel)
2004-07-01 15:08:18 +00:00
mpc
1b03e9a3ee
Who was the idiot who came up with the idea that booleans should be numbers?
2004-07-01 09:30:52 +00:00
mpc
2b951e3f61
Change 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.
2004-07-01 09:17:17 +00:00
mpc
f51e064cf6
*** empty log message ***
2004-07-01 02:23:59 +00:00
shendaras
9640e93895
imports
...
shendaras
2004-06-30 13:21:15 +00:00
shendaras
d5bd22040c
Crappy fix for incorrect Total Bytes Sent/Total Bytes Received via BandwidthLimiter.... ah.. just read the FIXME there.
...
shendaras
2004-06-30 13:16:05 +00:00
jrandom
dcdcb7521a
dont kill the context, we may need it when tearing down the runner (e.g. to get the time)
2004-06-30 04:11:59 +00:00
jrandom
4058c63884
dont be such a prude
2004-06-30 03:02:39 +00:00
jrandom
dd34548cc6
publish the tunnel congestion stat
2004-06-29 22:32:31 +00:00
jrandom
a6b5211fa7
congestion is only a warning, not an error
2004-06-29 22:30:14 +00:00
jrandom
4e89b9c363
reliability threshold = median of active and nonfailing (inactive nonfailing can be a large number of 0 reliability peers)
2004-06-29 20:32:36 +00:00
jrandom
f3e267d2d0
active 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
2004-06-29 19:45:26 +00:00
jrandom
2fd87dc1f1
when we select peers to test, lets use all of the reliable peers, not just well integrated peers
2004-06-29 19:41:30 +00:00
jrandom
40b6b77cfa
use the median reliability value of nonfailing peers for the reliabilty threshold, and simplify determining them for the speed and integration
2004-06-29 19:40:08 +00:00
jrandom
d0c61dbf4d
use the explicit max ID values (I2NPMessage.MAX_ID_VALUE and TunnelId.MAX_ID_VALUE)
...
logging
2004-06-29 19:32:46 +00:00
jrandom
1cd5a3fcf7
include the "addedBy" if we're debugging the job, not if we're debugging JobImpl
2004-06-29 19:29:57 +00:00
jrandom
af81cf2c50
explcitly define the max I2NP message ID value and validate against it
2004-06-29 19:28:40 +00:00
jrandom
04373c5d1b
just to be explicit about the max tunnel id
2004-06-29 19:25:23 +00:00
mpc
e9cdb0f78d
new library
2004-06-29 02:55:53 +00:00
mpc
021b933ad3
new library
2004-06-28 23:55:07 +00:00
mpc
9fd067c9da
Putting socks/threads/logger/misc in a separate library
2004-06-28 23:24:50 +00:00
jrandom
d3f3f3bdf7
use the socketManager's new setName function (to let us log more easily)
2004-06-28 13:23:24 +00:00
jrandom
72727dacd8
javadoc
2004-06-28 13:22:03 +00:00
jrandom
caeb2bc4e3
the 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
2004-06-28 13:21:18 +00:00
jrandom
13974b601f
added some stats (viewable on the router stat page when the i2ptunnel is run in the router's VM)
...
lots of logging
2004-06-28 13:18:18 +00:00
jrandom
cbc6aea8b4
logging
2004-06-27 21:20:31 +00:00
jrandom
290a2f7ccd
(ok this is a little silly)
2004-06-27 21:08:19 +00:00
jrandom
349e80f206
allow sending ASAP and remove any artificial delays
2004-06-27 20:53:32 +00:00
jrandom
5c1e001a73
logging
2004-06-27 19:39:45 +00:00
mpc
f312318fab
Finished winsock code cleanup
2004-06-27 13:07:06 +00:00
mpc
dc04b7cf09
Some winsock improvements
2004-06-27 09:12:05 +00:00
jrandom
77a8a46d8e
lets try to reduce creating new objects during finalization
2004-06-26 21:15:51 +00:00
jrandom
95c7cd55c2
logging
2004-06-26 21:15:16 +00:00
jrandom
5f0ef5e0e8
lets 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
2004-06-26 21:13:52 +00:00
jrandom
1f26c603e0
for 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)
2004-06-26 21:11:22 +00:00
jrandom
7e2227ad42
lets keep track of how many messages die on our queue due to us being slow
2004-06-26 21:07:07 +00:00
