Hello everyone!
During this year's Google Summer of Code I[0] will be working on reducing the
Round-Trip-Time (RTT) for preemptively built circuits.[1] My mentors are Mike
and Aaron.
A brief summary of the project:
RTTs of circuits can be measured by violating the exit policy of the exit node
Hi all!
I started a little late on this years GSoC project[0] which is about reducing
the RTT of preemptively built circuits. Since begin of July I have been
working on scripts for Tor path generation and Stream-RTT probing.
For the path generation script "path_finder.py" I decided not to reimp
Hi all!
During the last weeks I have been very busy working on my GSoC project which
is about reducing the RTT of preemptively built circuits.
There is now a single script called "rttprober"[0] that depends on a
patched[1] Tor client running a certain configuration[2]. The goal is to
measure
On Saturday 27 July 2013 04:41:45 Damian Johnson wrote:
> Hi ra, glad to see that you're using stem!
Sure, stem works really great!
> If you have any questions,
> suggestions, feature requests,
These parts were a bit tricky to figure out for me:
-) When I wanted to check if a c
On Monday 05 August 2013 07:25:20 Damian Johnson wrote:
> Yup. It's unfortunate that tor decided to include an 'Exit' flag with
> such an unintuitive meaning. You're not the first person to be
> confused by it.
Is this meaning at least documented somewhere and I have just read over it?
> > -) It
Hello!
Here goes my third status report on reducing the RTT of Tor circuits:
First of all I am happy to have received feedback from Damian which I
integrated into the RTT-probing script[0][1]. With this script I have already
gathered a big amount of data about the RTTs of circuits which I am sti
On Saturday 10 August 2013 02:37:48 Damian Johnson wrote:
> Hi Robert. Here's the relevant part of the spec...
>
> https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1738
Thanks. I will try to make that part more clear and open a ticket.
> > If requests are sent to Tor to create
On Saturday 10 August 2013 23:52:44 Damian Johnson wrote:
> If I understand this correctly you're thinking that multiple calls to
> extend_circuit() cause parallel EXTENDCIRCUIT requests, and the first
> response would be used for both callers. Is that right?
Yes.
> If so then I would be very int
Hello!
Here goes my fourth status report on reducing the RTT of Tor circuits:
I continued to evaluate lots of RTT-data of Tor circuits and drew some
conclusions from that:
*) The RTT measurements of circuits are subject to multiple influences and
hence very diverse.
*) There is no single distr
tl;dr
When building a circuit, measuring the RTT a single time could provide better
latency and anonymity while not affecting throughput. Multiple measurements
could be used for running real-time applications like VoIP or optimizing
throughput.
Despite the fact that the Tor network is curren
On Saturday 10 August 2013 02:37:48 Damian Johnson wrote:
> >> Yup. It's unfortunate that tor decided to include an 'Exit' flag with
> >> such an unintuitive meaning. You're not the first person to be
> >> confused by it.
> >
> > Is this meaning at least documented somewhere and I have just read o
On Wednesday 09 October 2013 23:44:18 Philipp Winter wrote:
> I am working on a Python-based exit relay scanner which should detect
> malicious and misbehaving exits. The design should have a reasonable
> balance between being fast/parallel and stressing the network as little as
> possible.
>
> I
On Saturday 16 November 2013 20:02:26 Damian Johnson wrote:
> Hi Aravindan. I haven't personally done much work with manual path
> selection, but RTT Prober does. I'd suggest looking at it as an
> example...
>
> https://bitbucket.org/ra_/tor-rtt/src/3a2ef9343d3054b8bcf37877d81d926400ed8
> 512/rttp
Hi, all!
Originally, I wrote the proposal for this year's GSoC, but nobody seems
willing to mentor it and the idea most probably needs more time to shape.
Hence, I post it on this list to get some feedback and let the idea evolve. (:
Best,
Robert
Problem statement
Tor's control protocol[0]
A short summary of the discussion on IRC:
It is generally considered a good idea to better encode data in Tor's control
protocol. In this case Protocol Buffers probably is more suitable for data
serialization than JSON. Though Flask seems to be a nice prototyping
framework, security concerns wer
reply-to: tor-dev
On Monday 29 September 2014 15:00:29 tor-admin wrote:
> since upgrading torland to 0.2.5.8-rc I see the below warnings. Is this
> something to worry about?
IMHO this might be due to a programming error in the circuit ID selection code
or possibly indicate a DoS attack.
>
On Monday 06 April 2015 12:35:27 Lluís wrote:
> After completing the "Stem" tutorial I tried to run one of
> the examples it points to, the "RTT Prober". I succeeded.
Wow. You are the first one who did (that I know of).
> However, after patching, recompiling and running the
> tor version they rec
On Thursday 10 March 2016 15:42:48 Zack Weinberg wrote:
> Before I go reinventing wheels, has anyone got code to measure network
> latency (either RTT or one-way packet travel time will do) from a
> chosen Tor exit to an arbitrary destination? Latency from client to
> exit would also be useful.
S
18 matches
Mail list logo
