On 29 October 2015 at 11:25, Nick Mathewson wrote:
>There are two possible ways a new connection to a directory
>authority can be established, directly by a TCP connection to the
>DirPort, or tunneled inside a Tor circuit and initiated with a
>begindir cell. The client can origina
aAt 20:56 11/5/2015 -0600, you wrote:
>On 5 November 2015 at 16:37, wrote:
>> By having a single thread handle
>> consensus retrieval and sub-division,
>> issues of "lost" relays should
>> go away entirely.
>
>So I'm coming around to this idea, after spending
>an hour trying to explain why it was
On 5 November 2015 at 16:37, wrote:
> At 11:47 11/5/2015 -0600, Tom Ritter wrote:
>> . . .
>>So them falling between the slices would be my
>>best guess. . .
>
> Immediately comes to mind that dealing
> with the changing consensus while
> scanning might be handled in a different
> but nonetheless
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi isis,
I am also not sure if we should have DYSTOPIC_GUARDS and UTOPIC_GUARDS
sets disjoint. It hurts the already fragile load balancing for Guards
and will cause lighter load on FascistFirewall Guards (ports 80/443).
I think usually users behind
At 17:37 11/5/2015 -0500, you wrote:
>
>. . .Consensus allocation worker. .
The consensus list manger could run
as an independent Python process and
"message" changes to the scanner
processes to avoid complexities of
trying to share data (I know very
little about Python and whether
sharing data i
At 11:47 11/5/2015 -0600, Tom Ritter wrote:
> . . .
>So them falling between the slices would be my
>best guess. . .
Immediately comes to mind that dealing
with the changing consensus while
scanning might be handled in a different
but nonetheless straightforward manner.
Why not create a snapshot
At 11:47 11/5/2015 -0600, Tom Ritter wrote:
> . . .
>So them falling between the slices would be my
>best guess. . .
Immediately comes to mind that dealing
with the changing consensus while
scanning might be handled in a different
but nonetheless straightforward manner.
Why not create a snapshot
Talked with Mike on IRC:
12:12 < tjr:#tor-dev> mikeperry: If you have a moment today, we'd
appreciate it if you could peek at the tor-dev thread 'stale entries
in bwscan.20151029-1145'
12:14 < mikeperry:#tor-dev> that seems to be one of the mails I lost
12:14 < mikeperry:#tor-dev> (had a mail fail
[+tor-dev]
So... weird. I dug into Onyx primarily. No, in scanner.1/scan-data I
cannot find any evidence of Onyx being present. I'm not super
familiar with the files torflow produces, but I believe the bws- files
list what slice each relay is assigned to. I've put those files
(concatted) here: h
On Thu, Nov 5, 2015 at 1:31 AM, Tim Wilson-Brown - teor
wrote:
>
> On 3 Nov 2015, at 13:01, Nick Mathewson wrote:
>
> Secondary meeting time and patch workshop:
> Monday at 0100 UTC (8:00pm EST, 5:00pm PST)
>
>
> Hi Nick,
>
> I'm not sure which time zones "Monday" refers to.
Arrg, my apologies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/11/15 17:43, Nick Mathewson wrote:
> On Wed, Nov 4, 2015 at 4:06 AM, Karsten Loesing
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> Hello developers,
>>
>> in the past few days I have been working on a grammar to parse
>> Tor
11 matches
Mail list logo
