Re: [tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs