[tor-dev] Some uncommon use cases for PT library transport selection

David Fifield david at bamsoftware.com
Thu Dec 19 03:41:42 UTC 2013

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

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
	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.

David Fifield

* fog is the transport combinator formerly known as Metallica; see

More information about the tor-dev mailing list