[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #20224 [Metrics/CollecTor]: Fix `BridgeDescriptorMappingsLimit` config option
#20224: Fix `BridgeDescriptorMappingsLimit` config option
-------------------------------+------------------------------
Reporter: karsten | Owner:
Type: defect | Status: needs_review
Priority: Low | Milestone:
Component: Metrics/CollecTor | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------+------------------------------
Comment (by karsten):
Hmm, no, that seems wrong or at least confusing, and on second thought my
patch above is wrong or at least confusing, too.
Here's a table with some timestamps that seem to be relevant here:
||= Row=||= `BridgeDescriptorMappingsLimit`=||= ''Milliseconds since the
epoch''=||=''ISO-8601 date/time'' =||
|| 1|| `0`|| `1475517323620`|| AD 2016-10-03 17:55:23.620 ||
|| 2|| `6120.7468`|| `946684799999`|| AD 1999-12-31 23:59:59.999 ||
|| 3|| `17077.7468`|| `-1`|| AD 1969-12-31 23:59:59.999 ||
|| 4|| `17102.6019`|| `-Integer.MAX_VALUE = -2147483647`|| AD 1969-12-07
03:28:36.353 ||
|| 5|| `-Integer.MAX_VALUE = -2147483647`|| `-185541111583476380`|| BC
5877475-12-05 17:55:23.620 ||
Explanations for these rows:
1. This is the current date/time, so if we had put in `0` as value for
`BridgeDescriptorMappingsLimit`, that's what the cut off time would have
been.
2. This is what we had put in before using `Integer.MAX_VALUE` as
parameter default value, and this date in 1999 is indeed small enough that
no bridge descriptor could have been published earlier.
3. This is what I had in mind in my patch above: pick `-1` as smallest
possible time in milliseconds since the epoch, but only because I had
misread 1999 as 1969. Oops.
4. That's what I think you're suggesting above, and I think it doesn't
really make sense to use this threshold to decide whether or not to fall
back to a date in 1999.
5. Here's the explanation for this bug, which I found out today: we're
not looking at an integer overflow/underflow, we're looking at BC dates
rather than AD dates, and we're not including AD/BC in the output date
format. Ugh!
My suggestion is to cut off at `1999-12-31 23:59:59` by hard-coding that
date/time in milliseconds as threshold. Untested code:
{{{
SimpleDateFormat formatter = new SimpleDateFormat(
"yyyy-MM-dd HH:mm:ss");
formatter.setTimeZone(TimeZone.getTimeZone("UTC"));
long cutTime = System.currentTimeMillis() - 24L * 60L * 60L * 1000L
* limitBridgeSanitizingInterval);
final long MIN_CUT_TIME = 946684799999L;
if (cutTime > MIN_CUT_TIME) {
this.bridgeSanitizingCutOffTimestamp = formatter.format(cutTime);
} else {
this.bridgeSanitizingCutOffTimestamp = "1999-12-31 23:59:59";
}
}}}
Does this make sense? If so, want to submit another patch?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20224#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs