Commit Graph

310 Commits

Author SHA1 Message Date
jrandom
c2a71ef756 include stats on bytes wasted (overflow from the buckets) 2004-07-28 23:35:48 +00:00
jrandom
e669110cf4 be sure to allow for clock skew 2004-07-28 23:34:42 +00:00
jrandom
f4cf31c13d less aggressive passive publishing 2004-07-28 23:34:02 +00:00
jrandom
7b23a5dcce keep track of wasted bytes (overflow from the bucket) 2004-07-28 23:32:51 +00:00
jrandom
b2fda0c79d catch errors earlier 2004-07-28 23:29:21 +00:00
jrandom
5af96f5ccb when we really need tunnels, always build them 2004-07-28 23:28:55 +00:00
jrandom
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
jrandom
5eaec4c841 only recurse one time 2004-07-28 03:51:38 +00:00
jrandom
ffcc34c4f9 heh, if it expires, we probably don't want to forward it (duh) 2004-07-28 03:50:30 +00:00
jrandom
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
jrandom
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
jrandom
c901bcf9b7 javadoc warning fix 2004-07-27 17:41:40 +00:00
jrandom
0ccf915a18 ewps 2004-07-27 17:39:52 +00:00
jrandom
52b1c0a926 * netDb searchReply and lookup messages now contain H(peer), not the peer's full RouterInfo
(making a searchReply message ~100 bytes, down from ~30KB, and the lookup message ~64 bytes, down from ~10KB)
* when we get the netDb searchReply or lookup message referencing someone we don't know,
we fire off a lookup for them
* reduced some excessive padding
* dropped the DbSearchReplyMessageHandler, since it shouldn't be used (all search replies
should be handled by a MessageSelector built by the original search message)
* removed some oddball constructors from the SendMessageDirectJob and SendTunnelMessageJob (always must specify a timeout)
* refactored SendTunnelMessageJob main handler method into smaller logical methods
2004-07-27 17:34:36 +00:00
jrandom
399865e6c8 increase the replenish frequency to occur every .1s
logging
2004-07-27 17:20:42 +00:00
jrandom
54aeab1524 send the full RouterInfo in the STS validation, not just the RouterIdentity (and in turn, store that RouterInfo in the local netDb)
logging
2004-07-27 17:17:16 +00:00
jrandom
91f83277e2 made incompatible with previous releases - the remaining commits before the next rev are NOT BACKWARDS COMPATIBLE
do NOT update until the next release
2004-07-27 17:15:55 +00:00
jrandom
c937cb2f07 no need to test a peer that we already know is up 2004-07-27 06:34:30 +00:00
jrandom
ebd150e473 we don't need to build a tunnel so often (just enough to keep things fresh)
cleaned up rebuild / verification process so that the select*TunnelIds will always return what is necessary
for the moment, don't automatically kill all tunnels of a peer who fails just once (they can recover)
logging
2004-07-27 06:19:44 +00:00
jrandom
9218f7b82c deal with not having tunnels a bit earlier 2004-07-25 23:51:07 +00:00
jrandom
edaf7aee5d * for the moment, remove the 'isFailing' check for peers who have failing tunnels
(we need a more sophisticated algorithm than the one in place for it to be effective)
* fix for the profileOrganizer to work safely in the sim
2004-07-25 23:46:55 +00:00
jrandom
43c18d0f4d (techincally) reduced the minimum bandwidth rate to 1KBps, but NO ONE SHOULD SET IT THAT LOW. do not reduce your limits below 6KBps until More Stuff Gets Done.
logging
2004-07-25 23:43:13 +00:00
jrandom
65d85f7479 the vast majority of messages on the live net are under 2KB 2004-07-25 23:40:08 +00:00
jrandom
476e23db5b new stat monitoring the netDb search reply message sizes 2004-07-25 23:35:50 +00:00
jrandom
ce3e7e623c handle disconnect while there are still requests pending 2004-07-24 17:54:49 +00:00
jrandom
f170ae741e 0.3.3, backwards compatible, to be released Real Soon 2004-07-24 02:13:37 +00:00
jrandom
740a2da702 more consistent html 2004-07-24 01:59:27 +00:00
jrandom
85c8e56417 fixed a strange bug when the .wait delay is really accurate (too accurrate..). thanks ZeroCool for help debugging this! 2004-07-24 01:10:11 +00:00
jrandom
9f4439583d expose some data points for the new console, and cleaned up some html
new piece of data exposed and maintained is a list of router contexts - shown as a singleton off RouterContext - allowing an app in the same JVM to find the routers (and chose between which one they want)
2004-07-23 17:36:29 +00:00
jrandom
ccb2600e67 when measuring capacity, consider data updated within the last hour as good, not just the last 5 minutes 2004-07-20 04:11:33 +00:00
jrandom
f06e21ff5a null check (oops) 2004-07-20 04:10:33 +00:00
jrandom
bb0817a2ec erg, expose the capacity calculator
(the last Router commit is a mod that ugha requested, but i think its ugly so its disabled atm)
2004-07-20 03:35:36 +00:00
jrandom
6911f865ca expose the capacity calculator 2004-07-20 03:34:52 +00:00
jrandom
fe28b2732c simple error condition check 2004-07-20 03:28:43 +00:00
jrandom
e8e8c37496 * implement new 'capacity' concept, which replaces the old 'reliability'
one for peer selection and organization.  reliability is kept around
  for the moment and shown on the router console, but only to provide a
  comparison (it is not used in any way)
* new stat in the TunnelHistory: failRate
* coallesce TunnelHistory stats (duh!)
* new ProfileOrganizer CLI ("ProfileOrganizer[ filename]*"
* implement reasonable 'failure' logic - if they are actively rejecting
  tunnels or tunnels they've agreed to are failing, mark them as failing
* when choosing peers to test, exclude all fast ones
2004-07-20 03:27:34 +00:00
jrandom
ef0f1ca1e7 include a lil more eye candy on the console (how active each tunnel is and last test time) 2004-07-20 02:57:55 +00:00
jrandom
31ca34b954 rate.getAverageValue returns the average of the last fully completed period, but we want to include the current partial period as well 2004-07-20 02:53:41 +00:00
jrandom
130399a1e7 0.3.2.3 (coming soon to a hard drive near you) 2004-07-16 21:12:27 +00:00
jrandom
f0b6cbaf89 logging 2004-07-16 19:14:39 +00:00
jrandom
707b173e77 differentiate between an explicit tunnel rejection (due to overload, etc) and an implicit one (the request timed out, the tunnels delivering the request failed, etc)
also, within the implementation of the profile, only mark the explicit rejections as a rejection
2004-07-16 00:17:28 +00:00
jrandom
4381bb5026 don't rip the peer's head off after multiple tunnel rejections - penalize them *once* for the instance (not once *per* instance) 2004-07-16 00:15:34 +00:00
jrandom
806d598a04 _context/getContext()
(missed one)
2004-07-15 05:23:18 +00:00
jrandom
e737e5c950 * work around the disagreement between different versions of sun's compiler and JVM:
Some of them think that its ok for an inner class of a subclass to access protected data of the
outer class's parent when the parent is in another package.
Others do not.
Kaffe doesn't care (but thats because Kaffe doesn't do much for verification ;)
The JLS is aparently confusing, but it doesnt matter whether its a code or javac bug, we've got to change the code.
The simplest change would be to just make the JobImpl._context public, but I loath public data, so we make it private and add an accessor
(and change dozens of files)
whee
2004-07-15 05:12:37 +00:00
jrandom
bbcde2f52b 0.3.2.2 (a lil installation testing and then i'll push) 2004-07-15 01:08:54 +00:00
jrandom
f6ef77429c some boundary cases for the queue pumper's wait time 2004-07-15 01:04:13 +00:00
jrandom
71a6cf4ee6 * adjust the algorithm to deal with IO bound requests:
if more tokens become available while the first pending request is still blocked on
  read/write (aka after allocation and before next .waitForAllocation()), give the tokens
  to the next request
* refactor the satisfy{In,Out}boundRequests methods into smaller logical units
2004-07-14 21:07:57 +00:00
jrandom
744ce6966f add a new throttle (and stats) based on send processing time
high send processing time and low job lag means the latency is coming from outside the jobQueue - aka bandwidth throttling
2004-07-14 20:01:40 +00:00
jrandom
d25cec02c2 clean up sorting for peer reliability
increase penalties for tunnel rejection, and keep track of the 10 minute rate as well as 1 and 60
2004-07-14 19:56:38 +00:00
jrandom
f02bf37fd3 stats and stats and stats
track the total allocated bytes correctly (even if we're throttled)
2004-07-14 19:54:04 +00:00
jrandom
304b9d41d7 on kaffe i've periodically seen some hangs in the jobqueue, so lets try being a bit more conservative with the synchroniation, and include some debugging output in the router console to help track it down (if this doesnt fix it) 2004-07-13 20:19:28 +00:00