Re: [tor-bugs] #9349 [Flashproxy]: flashproxy facilitator: Allow clients to specify transports

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

#9349: flashproxy facilitator: Allow clients to specify transports
----------------------------+-------------------
     Reporter:  asn         |      Owner:  dcf
         Type:  task        |     Status:  new
     Priority:  normal      |  Milestone:
    Component:  Flashproxy  |    Version:
   Resolution:              |   Keywords:
Actual Points:              |  Parent ID:  #7167
       Points:              |
----------------------------+-------------------

Comment (by dcf):

 Replying to [comment:21 infinity0]:
 > Replying to [comment:1 asn]:
 > > - (..) We will need to pass multiple bridges [to facilitators] in the
 future, so we might want to use a config file, where we put our bridges
 and annotate them with the transports they support. Possible example of
 such a config file:
 > > {{{
 > > websocket 1.2.3.4:5555
 > > webrtc 1.2.3.4:6555
 > > obfs2-websocket 1.2.3.5:5555
 > > }}}
 >
 > This might not scale well, since each bridge will need to distribute
 this information to every facilitator. Is there any way we can have the
 facilitator read this information from the bridge instead? From pt-
 spec.txt:
 >
 > {{{
 >  363   Bridges use transport lines in their extra-info documents to
 >  364   advertise their pluggable transports:
 >  365
 >  366      transport SP <transportname> SP <address:port> [SP arglist] NL
 > }}}
 >
 > Is the facilitator able to read this information?

 In the future, perhaps, the facilitator will be able to automatically pull
 relay descriptors from the consensus, so you don't have to set them up
 manually. But setting them up manually is what we should do in the short
 and maybe even long term. The facilitator doesn't need to know about every
 relay. The only reason to configure lots of relays is to deal with load--
 currently, one websocket relay is enough to handle the load. It's not like
 the case with bridges where you need a lot of them to make them hard to
 enumerate, apart from their capacity.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9349#comment:29>
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