[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3875 [Firefox Patch Issues]: TBB's Firefox should use optimistic data socks handshake variant
#3875: TBB's Firefox should use optimistic data socks handshake variant
-----------------------------------+----------------------------------------
Reporter: arma | Owner: mikeperry
Type: enhancement | Status: new
Priority: major | Milestone: TorBrowserBundle 2.3.x-stable
Component: Firefox Patch Issues | Version:
Keywords: performance roundtrip | Parent: #3890
Points: | Actualpoints:
-----------------------------------+----------------------------------------
Comment(by mikeperry):
Replying to [comment:5 arma]:
> > Therefore, we should first test a simple hack that has Tor always
respond with a connection success to see what the user experience is if
SOCKS hangs up in the case of errors rather than mucking around with
allowing data to be sent before an error comes back. If the UI doesn't
reflect this difference in a way the user is likely to understand in the
first place, it seems like there's little point in adding the complexity.
>
> I don't understand this last part. The expected gain is not in UI
responsiveness. It's in actually getting the pages faster.
What I meant was instead of creating a shim or changing *anything* on the
Firefox side, let's just test what happens with Tor Browser as it is today
if the Tor SOCKS handshake always responds with success to connection
attempts, only to close later if the data doesn't actually make it.
This test requires no change to Firefox to carry out.
If the user experience is not substantially different from what it is
without the SOCKS change on the Tor side, there is no reason to devote any
additional development effort either to change Firefox, or to introduce a
shim. We can just deploy the feature immediately.
If there are differences in the user experience, we can perhaps just
correct those to make them more uniform. In fact, the error messages
Firefox currently gives on connection failure are already pretty uniform,
regardless of the type of failure.
Is optimistic data already on by default for Tor 0.2.3.x? If I point my
TBB at a 0.2.3.x tor client, can I try this test today?
> I wonder if a patch to polipo would be simpler, and a good way to test
out how much of a difference the optimistic data feature makes.
While I have a penchant for distrusting academic results, I see no reason
to doubt Ian's own data in this case. It seems obvious to me there will be
significant improvement in load time by eliminating the round trip for
connection setup.
In fact, I was actually a little embarrassed I didn't think of it myself,
having worked at a company pretty much exclusively devoted to removing
round trips from braindead protocols.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3875#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs