[tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Oct 2 19:47:38 UTC 2019
#29206: New design for client -- server protocol for Snowflake
-----------------------------------------------+---------------------------
Reporter: cohosh | Owner: cohosh
Type: task | Status:
| needs_review
Priority: Medium | Milestone:
Component: Circumvention/Snowflake | Version:
Severity: Normal | Resolution:
Keywords: anti-censorship-roadmap-september | Actual Points:
Parent ID: | Points: 6
Reviewer: dcf | Sponsor:
| Sponsor28-must
-----------------------------------------------+---------------------------
Changes (by cohosh):
* status: needs_revision => needs_review
Comment:
Okay I made a lot of changes, and it's done in the sense that the
sequencing and reliability layer is fully integrated to the client and
server and all the features I think we want are there. I've squashed these
changes into two commits on a new branch:
https://github.com/cohosh/snowflake/compare/sequencing_squashed
The first commit adds the new SnowflakeConn network connection and the
second integrates it into both the client and the server.
Honestly I think it'll need another round of revisions for the following
reasons:
- The locks are a bit messy and I think we'll need more
- We don't currently have unit tests that check the client and server
integration and we should have them
- In my integration tests I'm seeing the server occasionally fail, but I
haven't figured out how yet
Right now there's a plain http test deployment of this server running on
ws://68.183.200.16 if you want to try it out.
Some additional notes:
- I see some motivation for another feature that allows us to set some
kind of FIN or RST flag to notify the client that the OR port has been
closed and the server that the client has closed the connection. Right now
each endpoint can't tell the difference between a problem with the
snowflake proxy and with an endpoint.
- Even though we aren't closing the OR connection on the server side when
a snowflake dies, from my tests it looks like the second snowflake
connection isn't happening fast enough and I'm still getting a `connection
reset by peer` error when I try to write to it again.
Perhaps 10s is too long a timeout?
Is there a client keep-alive functionality that should happen that we can
simulate at the bridge?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29206#comment:27>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list