[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake
#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