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:       
 Keywords:              |         Parent:  #7167
   Points:              |   Actualpoints:       
------------------------+---------------------------------------------------

Comment(by dcf):

 Replying to [comment:4 asn]:
 > I attached another `design.txt` patch. This one also specifies the new
 flashproxy poll format.

 I agree with this patch.

 > BTW, do you think I should also specify the way that the facilitator
 should handle flashproxy polls that include transports? As I see it, when
 the facilitator gets a flashproxy poll that includes transport ''X'', it
 should:
 > a) See the client registrations that use transports, and see if any of
 them have ''X'' as their ''outermost transport''. To do this, we will need
 to modify `get_reg_for_proxy()` and `RegSet` (and maybe more stuff).
 >
 > b) Then it needs to find a registered bridge that supports the transport
 chain that the client registration asked for. We will need a config file
 containing bridges and some utility functions to do this.
 >
 > c) Finally it needs to send the new-style response to flashproxy that
 contains the client, the relay and the transports they support. >To do
 this, we will need to modify `fac.py:get_reg()` or something like that.
 >
 > I'm not sure I understand the way `RegSet`s work. What's this tier
 business? Should I make `RegSets` transport-aware or would you prefer to
 do this in another way?

 I think your understanding is correct. We don't have to specify the
 internal steps taken by the facilitator, only that it it returns to the
 proxy a client and relay address compatible with one of the proxy's
 offered transports.

 We say that the client with the fewest proxies is the one that should be
 served next. A reg is put in the tier equal to the number of proxies it
 currently has. You can get the next client in ''O''(1) by popping the
 lowest non-empty tier. Likewise moving between tiers is ''O''(1). It could
 also be implemented as e.g. a priority queue.

 `RegSet` is just a bag of registrations, that knows how to extract the
 registration with the highest priority.

 Currently we have `get_reg_for_proxy`--the only thing we use the proxy
 address for is to decide IPv4 versus IPv6. This is handled by having two
 instances of `RegSet`: `REGS_IPV4` and `REGS_IPV6`. So maybe we can have
 one instance of `RegSet` for each outermost transport, and
 `get_reg_for_proxy` will also get the list of transports the proxy
 supports.

 We can check, at client registration time, whether the client has any
 known matching relays (matching in the sense that they have a compatible
 transport chain). Otherwise we just drop the useless registration. That
 way we can assume that all client regs have a relay match, and are only
 waiting for a compatible proxy to appear. Suppose a websocket proxy
 appears, we consult the websocket `RegSet` and find the highest-priority
 websocket client, then do a fast lookup to find the relay it should be
 matched with.

 > Also, is the IPC mechanism of flashproxy documented somewhere (the
 `FROM`, `PUT` etc. commands that are passed around?)

 Sorry, it is hardly documented. The doc comment on `parse_transation`
 shows the syntax. My goal was to make the protocol hard to wrongly
 implement. Quoting of strings is obligatory. A `PUT` transaction currently
 looks like:
 {{{
 PUT CLIENT="1.1.1.1:1111" FROM="2.2.2.2:2222"
 }}}
 `PUT` happens when a client makes an HTTP POST registration request. The
 `FROM` part is not used currently; I intended it to be used for rate
 limiting, or to allow trusted registrants not to be bound by rate
 limiting. A `GET` transaction is
 {{{
 GET FROM="3.3.3.3:3333"
 }}}
 Here, `FROM` is the proxy's address, and it is what gets passed to
 `get_reg_for_proxy`.
 Responses have the same format. They can look like
 {{{
 OK CLIENT="1.1.1.1:1111" RELAY="4.4.4.4:4444" CHECK-BACK-IN="600"
 }}}
 or
 {{{
 NONE CHECK-BACK-IN="600"
 }}}

 > (I might also need some tips on testing/debugging the facilitator.)

 `doc/facilitator-howto.txt` tells how it is set up. You can skip some
 steps for your own testing, for example you don't need an SSL cert, and
 you don't have to use Apache, you can use any simple web server capable of
 serving CGI. You don't need to run facilitator-email-poller nor
 facilitator-reg-daemon; just use the HTTP rendezvous and `flashproxy-reg-
 http` for testing.

 Some programs allow you to override the default public facilitator. For
 example use `flashproxy-reg-http -f http://localhost:8000`.

 Try the `-d` option to `facilitator` to log to stdout.

 Arlo has set up a facilitator in the past.

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