Opened 21 months ago

Last modified 17 months ago

#29293 new task

New Design for client -- broker protocol for Snowflake

Reported by: cohosh Owned by:
Priority: High Milestone:
Component: Circumvention/Snowflake Version:
Severity: Normal Keywords: snowflake, bridges, broker, ex-sponsor-19
Cc: ahf, dcf, arlolra, cohosh Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor28-must


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

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

Some things to keep in mind are that we'd like to give the clients multiple ways to connect to the bridge distributor and should get the necessary information for multiple types of bridges. We also need various ways for identifying or distinguishing clients that will aid our bridge partitioning system (e.g., salmon, hyphae). This could be by supplying email addresses, secrets, etc.

Child Tickets

Change History (4)

comment:1 Changed 21 months ago by cohosh

See also existing tickets for various ways to connect to this broker:

comment:2 Changed 19 months ago by dcf

One of the problems with the current client–broker protocol is its use of HTTP response codes to carry some of the information in the broker's response.

For example, when the client requests /client, the broker returns either a 200 with a response body, an empty 503, or an empty 400. This is awkward when doing rendezvous over non-HTTP channels, or even over AMP cache, which doesn't reliably pass through the server's original status code (see comment:24:ticket:25985). As it is now, if the client is operating in HTTP mode, it needs to look at the status code; but if it's operating in AMP cache mode, it needs a separate code path that ignores the status code and instead looks for the equivalent information somewhere in the response body.

It would be easier if all the necessary information in the broker's response were in the HTTP body, because that's easier to port to other channels.

comment:3 Changed 17 months ago by gaba

Keywords: ex-sponsor-19 added

Adding the keyword to mark everything that didn't fit into the time for sponsor 19.

comment:4 Changed 17 months ago by phw

Sponsor: Sponsor19Sponsor28-must

Moving from Sponsor 19 to Sponsor 28.

Note: See TracTickets for help on using tickets.