Hi i am a new partner in tor-dev can you help me te understand the stuffs here Le 2 août 2019 16:25, "Nick Mathewson" <ni...@torproject.org> a écrit : > > On Tue, Jun 25, 2019 at 9:24 PM <n...@neelc.org> wrote: > > > > Hi tor-dev@ mailing list, > > > > I have a new proposal: A Tor Implementation of IPv6 Happy Eyeballs > > > > This is to implement Tor IPv6 Happy Eyeballs and acts as an alternative > > to Prop299 as requested here: > > https://trac.torproject.org/projects/tor/ticket/29801 > > > > The GitHub pull request is here: > > https://github.com/torproject/torspec/pull/87 > > > > Thank You, > > Hi, Neel! Thanks for working on this; I believe it's come a long way > in the last month! > > Here are a few questions based on the current PR. > > * We need to revise the "relay selection changes" to match the > vocabulary of guard-spec.txt. It's easy to say "select at least one > relay with an ipv6 address", but it's not trivial to do so in > practice. (Also, do we do this always, or do we do this only when we > think we can connect to ipv6 addresses?) > > * We also need to think about what this algorithm means in terms of > guard-spec.txt's data structures. Does it mean that each connection > to a guard is replaced with two? Does it mean that some of the > reachability variables are replaced by two? > > * The proposal considers TCP success vs authentication success as > indicating that a connection has succeeded. There is a good > alternative that reduces CPU load, however. The TLS handshake has > multiple phases, and the expensive CPU stuff all happens after we > receive a ServerHello message. If we treat an incoming ServerHello as > meaning that the connection will be successful, we can avoid most > wasted handshakes. > > [This would definitely not handle the problem where one of a server's > addresses is correct but the other address is a different server > entirely, but I hope we can catch that earlier in data flow, possibly > at the authorities.] > > * The 1.5 second delay, and associated other hardcore times, should be > a network parameter, transmitted in the consensus. 1.5 seconds can be > the default, but we will want to keep the ability to tune it later on. > > * For pluggable transports, do we want to manage this process > ourselves, or delegate the decisions to the PT? Each option has its > own benefits and risks. > > cheers, > -- > Nick > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev