On Wed, Dec 18, 2013 at 07:41:42PM -0800, David Fifield wrote: > I've been thinking about a couple of tricky use cases for pluggable > transport libraries, and whether we should do anything to try to support > them. > > The first use case is the flashproxy/websocket use case. > flashproxy-client recognizes the two transport names "flashproxy" and > "websocket" as synonyms. That is, tor can ask for either one and they > will work equivalently. But what should happen when tor asks for "*"; > i.e., the activation of all supported transports? We want to start only > one SOCKS listener, for the preferred name "flashproxy", not a separate > listener for every synonym. The way that you would indicate you support > two transport names would be done like this in pyptlib and goptlib > respectively: > ptclient.init(["flashproxy", "websocket"]) > ptInfo, err := pt.ClientSetup([]string{"flashproxy", "websocket"}) > but neither of those work for this use case, because if tor asks for > "*", you get two listeners. Maybe we don't care about this use case, > because as I understand it, tor will never ask for "*" anyway. > > The second use case is the fog* use case. As a server, we may not want > to declare all the transports we support in advance. Rather, we may > prefer to look at the names of the transports tor has asked for, and > decide for each one whether we support it. The idea here is that since > we can arbitrarily chain a set of transports, we can't just enumerate > all possible chains and declare those as the transport we support. Both > pylib and goptlib require you to list all the transports you want to > support on initialization. We would like for tor to be able to ask for a > transport name like "obfs3|cbr|obfs3|websocket", and we check to see > whether we are able to construct such a chain. The current idea is to > only support a small number of predefined chains in a configuration > file, so that we can in fact declare them all in advance. > https://trac.torproject.org/projects/tor/ticket/9744
What I did in goptlib, in both cases, is to have the list of transports given to ClientSetup and ServerSetup be used only when the "*" list of transports is requested by tor. In all other cases, you get the full list of requested transports and have to filter them at the application level. David Fifield _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev