onion vs tor+exit: which will win? which should win?

[Brian Warner]

If a FURL contains both tcp: and tor: (perhaps from a server that wants to assist Tor-capable clients, but remain accessible to non-capable clients), and the client is configured to use Tor for tcp: hints too (because it wants to hide its own IP address), what will happen?

I think the two connections will race, and I suspect the tcp: hint will win (it will go through an exit node, but it doesn't have to look up the onion descriptor, so I think it'll have less work to do).

But I think we'd prefer the tor: (onion) hint to win, since that reveals less information to the internet at large.

Is there a clean way to make this more likely to happen? If hints were processed as a group, we could make the tcp handler notice the presence of the tor handler, and then stall itself for a few seconds, to give the tor handler a chance to win. But connection handlers are pretty independent: they're unaware of each other.

Maybe connection-handlers could return a priority value (synchronously, before hint_to_endpoint is called). If there are multiple hints with different priorities, the overall connection manager could impose a delay.

Or maybe the handler could get an additional argument that says "by the way, here are the other handlers that I'm about to ask, feel free to let that influence your behavior". We know all the handlers that will be used early (once we see the hint types), so this wouldn't be too hard to implement. And then the TCP handler could notice the Tor handler and stall itself. We might add a marker Interface to let the connection manager know that this handler is capable of understanding the extra argument. Or add a static class attribute, or something.