Skip to content

Interaction between RPC and SOCKS (or similar) datastreams

As part of our RPC design, we need the ability for applications to open a connection (e.g. via SOCKS) and have them managed by an RPC session.

Here is (roughly) the design that we came up with. (This is a summary of a discussion @Diziet and I had on an etherpad.)

  • From a TorClient object in an RPC session, it is possible to get a global (non-RPC-session-specific) identifier string.
  • If you include this client identifier properly1 in your SOCKS request, your stream opened via that TorClient.
  • In your SOCKS request, you may also include a stream identifier that you make up.
  • It is possible for the RPC session to look up the stream object (or a StreamHandle, see #847 (closed)) using the TorClient object and the stream identifier.
  • If you want to pass any other parameters to the stream creation process, you create a new TorClient or TorClient-like object for them.

  1. There is a question of how to properly bundle this information. One possibility is to just shove it in the SOCKS4 authentication or SOCKS5 username/password field, like we do for so many other things. But that has other semantics: it's also used for stream isolation. Will that cause a conflict? Another possibility is to define a new address type, or a new authentication mechanism. A third option is to move everybody to HTTP CONNECT, and use headers to pass this information. ↩