Implement at least one ExternalAccessDiscoverer that deals with NAT/UPnP/Whatever

[monoman]

Search // TODO1:

A placeholder public class DummyExternalAccessDiscoverer was implemented that mimics the current implementation of resolving the local IP Address from a name, and trying to find an available port using an offset from the default one. what this implementation misses is the overriding from configuration, for the name and port to start with which can be implemented by the NodeSink, if needed.
This works great for testing multiple node instances in the same machine or in machines in the local network, but breaks to connect to nodes published with public names/IP address in the internet like the AppRegistry for TestNet Vesta, already online.

Nodes need to find which address/port they can promote and receive requests on to fully become part of the network.

This interface enables the TcpListener instance to be started with a local address & port, but return the external address and port other nodes will be able to connect with this node, for the node to promote itself.

Possible solutions:

• Use UPnP to find the appropriate gateway and open some port in it to forward to the listener (ideally should try to open the default port, but it may be in use already)
• Use echo/reverseDNS servers to discover the external IP/dns address we can write out, but I'm not sure that port forwarding rules are lax by default, so that we can hope to find that we can listen on the same address. Nodes not in the public zone or in the DMZ, will never be able to be reached in any sane organization. For internal nodes we will need to implement proxying and keep outgoing connections as listening ones and this is out of scope.
• Use configuration to force internal/external address/port pairs, so that DevOps setup forwarding rules work without further
• Look at Neo for further ideas, also Bitcoin (C/C++) and Ethereum if needed
• Look at Open.NAT for inspiration (license is compatible, it seems)

Estimate: 1 man-month

Hurdles:

• Too much exploration to do, may take more time than expected to find some reliable solution, that works across Windows/Linux/MacOS/Docker. Android/iOS may not support nodes that are P2P reachable, but probably will channel interactions through proxies which are out of scope.
• Also in the case of IPv6 public addresses being enabled and routable in the machine/VM, we should use then and avoid NAT completely.