Opened 3 weeks ago

Last modified 10 days ago

#29207 new task

New design for broker -- proxy protocol for snowflakes

Reported by: cohosh Owned by:
Priority: Very High Milestone:
Component: Obfuscation/Snowflake Version:
Severity: Normal Keywords: snowflake, design, network-team-roadmap-2019-Q1Q2
Cc: dcf, arlolra, cohosh Actual Points:
Parent ID: Points: 5
Reviewer: Sponsor: Sponsor19

Description (last modified by cohosh)

This is related to the Snowflake protocol design tickets #29206 and #29293.

We want to write these protocols in a way that is not Snowflake-specific but allows any type of bridge to connect to or poll our broker/BridgeDB bridge distribution service.

The idea is that in the beginning we will start with very reliable "bridge" (which could be snowflakes) that perhaps rotate IP addresses every month or so. After that we can collect measurements and move towards more ephemeral "bridges".

Some things to keep in mind are the types of information that the snowflakes give to the broker (such as proxy version/type) to allow for metrics. This information might change so we'll want a flexible and extensible protocol.

Child Tickets

Change History (6)

comment:1 Changed 3 weeks ago by cohosh

Cc: cohosh added

comment:2 Changed 3 weeks ago by cohosh

Sponsor: Sponsor19

comment:3 Changed 3 weeks ago by cohosh

Description: modified (diff)
Keywords: snowflake design added

comment:4 Changed 2 weeks ago by gaba

Points: 5

comment:5 Changed 2 weeks ago by cohosh

As referenced in #29426, the broker currently gives proxies a 504 message if no client is available which is a questionable design:

2019/02/07 12:11:51 broker returns: 504
INFO: peerconnection.go:468: fired OnIceCandidateError: 143
2019/02/07 12:12:01 broker returns: 504

At the very least it makes logs confusing.

comment:6 Changed 10 days ago by gaba

Keywords: network-team-roadmap-2019-Q1Q2 added
Note: See TracTickets for help on using tickets.