It seems like a fairly common idiom to setup some sort of TCP server with a kernel selected port via an endpoint descriptor like this:
def getListeningPort(listeningPort): address = listeningPort.getHost() endpointDesc = convertAddressToEndpointDesc(address) sendAnnouncement(endpointDesc) endpoint = serverFromString(self.reactor, 'tcp:0') d = endpoint.listen(MyProtocolFactory()) d.addCallback(getListeningPort) ... later on a remote client receives the endpoint string and uses it to connect: endpointDesc = getAnnouncement() endpoint = clientFromString(endpointDesc) endpoint.connect(MyFactory()) For the Tor Hidden Services endpoint (work in progress) I've implemented IAddress and IListeningPort: https://github.com/david415/txtorcon/blob/endpoint_parser_plugin-rewrite4/txtorcon/torconfig.py#L106-L160 Creating a Tor Hidden Service endpoint without specifying a "hidden services directory" containing an rsa private key and a hostname file causes the endpoint object to create a new Tor Hidden Service. This is conceptually similar to the case where we create a TCP server endpoint with the port number set to zero. In both cases the fired IListeningPort implementation should tell us what we need to know in order to construct a client endpoint descriptor string. I was thinking that it would be great if the process of creating these endpoint strings from an IAddress implementation should/could be endpoint agnostic. It should work even if the endpoint descriptors have no notion of hosts or ports... For protocols like TCP it is non-obvious how to do this correctly because the host cannot be correctly guessed in the face of NAT routers etc... as mentioned here: https://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.ITransport.html#getPeer This is why the above TCP example is flawed; however the equivalent example with the Tor endpoints will work perfectly and is not affected by NAT routers: https://github.com/david415/txsocksx/blob/tor_deferred_dispatcher/examples/tor-dispatch-onion.py#L39-L63 The TorOnionAddress has all the information it needs to create a Tor client endpoint... except for the endpoint type identifier and a set of rules from constructing endpoint strings... which perhaps the TorOnionAddress should get from the TCPHiddenServiceEndpointParser? Perhaps if the user were to pass in more information to the server endpoint object then the TCP IListeningPort implementation would be able to correctly produce a TCP client endpoint strings. Or maybe this just doesn't make sense for protocols like TCP. On Mon, May 19, 2014 at 3:59 PM, <exar...@twistedmatrix.com> wrote: > On 06:27 am, a...@roiban.ro wrote: >> >> This email is bases on comment from >> https://twistedmatrix.com/trac/ticket/5999 >> >> I fail to see the reason why SSHTransportAddress exist and why would >> anyone need It. > > > Here are a couple ideas. > > You have a library that accepts a connection and does some things with it. > You want to log the operations that are taken using the connection and you > want to include information in those logs about which connection you did > things with. You choose to use the addresses of the local and remote sides > of the connection to identify it. > > You have a library that accepts a connection and wants to be able to set up > another connection like it to the same remote address. You get the remote > address using the transport's `getPeer` method. > > Though you may have established the SSH connection over a TCP/IPv4 > connection, neither of these uses can be accomplished if the SSH connection, > when treated as a transport, merely uses an `IPv4Address` instance to > represent the address of the remote end of the connection. Using > `IPv4Address` gives you no way to differentiate between an SSH connection > running over a TCP/IPv4 connection and a plain TCP/IPv4 connection without > SSH. > > In practice, `SSHTransportAddress` is missing the information you would need > to implement either of these scenarios. However, that seems more like an > argument for adding the missing information to that address type rather than > discarding the address type. > > Jean-Paul > > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python