Skip to content

Brainstorming TrRemoteConnection rearrangement

sanity edited this page May 21, 2011 · 6 revisions

TrRemoteConnection

  • This should contain everything required to connect to a remote node (right now it doesn't contain the public key, or whether the node will accept unilateral connections)

PROBLEM: If A connects to B unilaterally, then B doesn't have the ability to connect back to A because it doesn't have A's public key

So, we've been using TrRemoteConnection to identify nodes, even though we might not be able to connect to them.

So, we need to separate something that identifies a remote node, from something that allows us to connect to a remote node. eg. an IP address and port allow us to identify a remote node, but do not allow us to connect to it.

Also, a node's identity may be associated with multiple mechanisms to connect to it. Perhaps we could even have several different ways to identify a remote node.

Clone this wiki locally