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:  needs_review
     Priority:  normal      |  Milestone:
    Component:  Flashproxy  |    Version:
   Resolution:              |   Keywords:
Actual Points:              |  Parent ID:  #7167
       Points:              |
----------------------------+--------------------------

Comment (by dcf):

 Replying to [comment:35 infinity0]:
 >
 https://github.com/infinity0/flashproxy/compare/bug9349_server_endpoints...bug9349_server_urlparam
 >
 > Here is my code implementing the url-param syntax stuff. It builds on
 top of endpoints, since it takes advantage of some of the encapsulated
 data structures introduced in that branch.
 >
 > In the interests of a more consistent language for representing an
 (address,transport) pair, I tweaked dcf's suggested syntax above slightly:
 >
 > - client registration requests now look like "client-addr=_&client-
 transport=_"
 > - facilitator responses now look like "client-addr=_&client-transport=_
 &relay-addr=_&relay-transport=_"
 >
 > (I changed the facilitator response, since the reason we did the syntax
 in the first place was to get rid of dynamic keys in the param list. I
 added "-addr" so that the transactional representation is sane and
 constant.)
 >
 > Old client registrations of the form "client=_" still work, with implied
 transport=websocket.

 We should try to be backward compatible in this case. We won't be able to
 update all proxies instantly. As you say in comment:36, let's have
 `client` and `relay` in place of `client-addr` and `relay-addr`. `client-
 transport` and `relay-transport` are good names.

 > - the transactional representation in fac.py now looks like "CLIENT
 addr=_&transport=_" and "RELAY addr=_&transport=_", reusing the qs
 parse/format code

 I really don't like this :( Here's what I see the facilitator returning to
 a `GET`:
 {{{
 OK CLIENT="client-transport=websocket&client=1.1.1.1%3A9000" RELAY="relay-
 transport=websocket&relay=0.0.1.0%3A1" CHECK-BACK-IN="600"
 }}}
 I want the internal facilitator protocol to be very simple and not have
 embedded syntaxes.
 Is there something wrong with the straightforward syntax?
 {{{
 OK CLIENT="1.1.1.1:9000" CLIENT-TRANSPORT="websocket" RELAY="0.0.1.0:1"
 RELAY-TRANSPORT="websocket" CHECK-BACK-IN="600"
 }}}

 > The addition of "-addr" does cause one slight untidiness - previously,
 the facilitator gave an empty "client=" value as a response to mean "no
 registrations available". This sort of fit into the old syntax, but is not
 really consistent with the new syntax. The old client= behaviour remains;
 we could change it to "look more" like the new syntax; but actually IMO we
 should pick an entirely different way to communicate this, since it is an
 exceptional status for the proxy.

 `client=` is at least an unambiguous and backward-compatible way to
 indicate that there is no client registration. In the very early days we
 might have used a 404 to do it, but stopped because that caused a problem
 with Flash's HTTP retriever or XMLHttpRequest or both. I don't care too
 much as long as it works. If you can think of a better way, that's fine.

 Getting no client happens much more frequently than getting a client.

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