On Thu, 10 Oct 2019 at 10:37, George Kadianakis <desnac...@riseup.net> wrote: > So are you suggesting that we can still do SOCKS error codes? But as > David said, some of the errors we care about are after the descriptor > fetch, so how would we do those?
Only 'X'F3' Onion Service Rendezvous Failed' - right? I think David is proposing we just don't do that one because in his experience it's pretty rare. > Also, please help me understand the race condition you refer to. I tried > to draw this in a diagram form: > https://gist.github.com/asn-d6/55fbe7a3d746dc7e00da25d3ce90268a I edited this: https://gist.github.com/tomrittervg/e0552ed007dbe50077528936b09a2eff Whose first diagram (normal situation) is correct? Something looks off in yours... You obviously know tor much better; but latency gain for optimistic socks doesn't come from sending the HTTP GET to tor sooner, it comes from sending it to the destination sooner - so I think that the GET must travel to the destination before the destination replies with CONNECTED, doesn't it? Anyway, I tried to illustrate Matts race condition as I understand it; but I am entirely unconcerned with it. There's no way it's going to take the browser more time to generate a HTTP GET and send it over SOCKS than it's going to take tor to roundtrip a rendezvous setup. > IIUC, for onions the advantage of opportunistic SOCKS is that we would > send DATA to the service right after finishing rendezvous, whereas right > now we need to do a round-trip with Tor Browser after finishing > rendezvous. Is that right? > > If that's the case, then sending the SOCKS reply after the rendezvous > circuit is completed would be the same as the current behavior, and > hence not an optimization, right? Correct. > And sending the SOCKS reply after the introduction is completed (as > David is suggesting) would be an optimization indeed, but we lose > errors (we lose the rendezvous failed error, which can occur if the > onion service is under DoS and cannot build new circuits but can still > receive introductions). Yup. > What other problems exist here? I'll have to think about it more at a time I'm better equipped to. -tom _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
