#28547: Monitor relays that are not measured by each sbws instance -------------------------------------------------+------------------------- Reporter: teor | Owner: (none) Type: defect | Status: new Priority: Medium | Milestone: sbws: | 1.1.x-final Component: Core Tor/sbws | Version: Severity: Normal | Resolution: Keywords: tor-bwauth, sbws-1.0-must- | Actual Points: moved-20181128 | Parent ID: #25925 | Points: Reviewer: | Sponsor: -------------------------------------------------+-------------------------
Comment (by juga): Replying to [comment:11 teor]: > > 2. generate could be other thread that happens every hour, instead of a different process, so that it can access to the results without the need to read them back from the results files. > > - pro: eliminate the need to have to run an external command, to have to write first the results files and then read them again > > - con: bigger change > > - con: if sbws restarts, some results for the day are lost reusults can be also written as they're gotten > - con: is this a breaking change? Does the command-line interface to generate change? the command generate could still exist, just no need for it if the scanner command also do it. > > > I'm a bit more inclinated to 2, because that would easy further refactorings for > > - not having all bandwidth values triplicated in v3bwfile, relaylist and resultdump. I can explain more about htis > > Why is this a problem? It's currently just a bit hard to modify and maintain > > > - not having to create new ResultError classes to monitor the relays > > sbws should make it easy to add new keys. If it's not easy, we should re-design the code so it is easier. ok, will see what's the easier way > Here's what I think: > > * sbws needs to persist the results every hour, so that it can read them after a restart or crash. Otherwise, we lose a day of data every time sbws restarts. my mistake here, the results are written as they are obtained: https://gitweb.torproject.org/sbws.git/tree/sbws/core/scanner.py#n353. So there's no need for 1. and 2. could be an improvement, but i think it's not needed so far -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28547#comment:12> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs