Custom Query (26254 matches)


Show under each result:

Results (88 - 90 of 26254)

Ticket Resolution Summary Owner Reporter
#1296 fixed CircuitBuildTimes should have an option to disable mikeperry mikeperry

There should be both an option to disable CircuitBuildTimes timeout gathering and also some logic that autodetects when to disable it. In particular, it should be disabled automatically for directories, and clients that cannot write a Tor state file. There should also be a torrc option to disable it manually for tordnsel and other services.

[Automatically added by flyspray2trac: Operating System: All]

#1298 fixed Tor does not treat multiple streams fairly nickm mikeperry

Camilo Viecco noticed that Tor seems to have problems multiplexing streams onto the same circuit, and I have been able to reproduce this. In a simple test setup, I had 6 streams running on the same fast 2 hop circuit, and one stream would get 100-200K/s and the rest would only get 1K/s. He also ran the following experiments:

"The tests that I made seem to show that the problem was on multiplexing multiple streams on the same circuit. I ran tests on a private Tor network and the problem seem to be limited to a per circuit limit . (I tried multiple clients on the same host, using the same circuit path, and the problem seems to be related to the a circuit case, that is the 4th stream on each circuit ). The private network was using a high speed low latency network (at most one router between hosts, with at least 1GBs paths between nodes, switches and routers).

Therefore my guess is that the problem lies on the client or exit node socks code."

Neither of us have yet tested the same client with different circuits, as this is difficult to pin down due to circuit performance variance.

Child Tickets:

exit relays don't consider local cell queue when hearing sendme
circuit_resume_edge_reading_helper is highly unfair
Stream starvation due to activation order in circuit_resume_edge_reading_helper()

#1300 fixed Authority that doesn't make a consensus never fetches one from elsewhere arma

If moria1 fails to participate in making the consensus (e.g. it's down, or it doesn't support the consensus method that is chosen for the consensus), then it doesn't have a consensus for that period. It should realize it doesn't have the newest consensus, and try to fetch one from the other authorities.

This bug is especially relevant while we have authorities that don't like the consensus method in use -- currently dizum and dannenberg haven't upgraded, so they never sign the consensus, so any clients (or relays!) who ask them for a consensus have to retry elsewhere. I imagine the bug slows down bootstrapping too.

[Automatically added by flyspray2trac: Operating System: All]

Note: See TracQuery for help on using queries.