add user-defined conn select alg and user-defined dest select alg

[lnykww]

When we turn on autorelay, the machines behind the NAT will use the relay to establish the connection. At this time we do hole punching, we need to establish a new connection instead of the relay connection. So we need dial direct to some addrs and ignore there is already a connection(witch is relayed) for the peer in swam.

[Stebalien]

I wonder if we should just add options to the Dial function? Really, we just want to be able to specify constraints on the connection. We may just want a opts.Filter(func(m ma.Multiaddr) bool) option.

---

With respect to this code, this is going to be pretty buggy. We have a lot of code that expects that we'll only have one in-progress dial to a given peer at a time. A correct solution is going to require quite a bit of work.

[raulk]

@lnykww we have a WIP PR that modularises the dialer (#88) so that applications (and subsystems like autorelay) can modify the behaviour. Under that model, you could inject a Planner into the dialer that uses a context.Context attribute to ignore relay addresses in the dials that pertain to hole punching.

[vyzo]

What's the context for this? It needs a whole coordination protocol if we are to do hole punching, and I am not convinced a direct dial is the solution -- let alone that our current multistream protocol can't handle simultaneous open...

[Stebalien]

What's the context for this? It needs a whole coordination protocol if we are to do hole punching, and I am not convinced a direct dial is the solution -- let alone that our current multistream protocol can't handle simultaneous open...

I believe this is just for "dial back". That is, if I'm NATed and I get an incoming connection via a relay, I can "dial back" to could a direct connection. However, I can't currently do that without closing the existing connection first. Ideally, I'd be able to create this new connection and then the swarm would prefer it for new streams (well, ideally we'd migrate...).

[lnykww]

I wonder if we should just add options to the Dial function? Really, we just want to be able to specify constraints on the connection. We may just want a opts.Filter(func(m ma.Multiaddr) bool) option.

With respect to this code, this is going to be pretty buggy. We have a lot of code that expects that we'll only have one in-progress dial to a given peer at a time. A correct solution is going to require quite a bit of work.

@Stebalien I will think carefully about how to do this place. And create the v2 version.

@lnykww we have a WIP PR that modularises the dialer (#88) so that applications (and subsystems like autorelay) can modify the behaviour. Under that model, you could inject a Planner into the dialer that uses a context.Context attribute to ignore relay addresses in the dials that pertain to hole punching.

@raulk
Nice! I will read this PR carefully. Does this PR have the expected time to merge into master? If it still takes a while, I may be more inclined to implement this feature on the current master version.

[lnykww]

What's the context for this? It needs a whole coordination protocol if we are to do hole punching, and I am not convinced a direct dial is the solution -- let alone that our current multistream protocol can't handle simultaneous open...

@vyzo
Sorry for the background of this question is not carefully described.

The demo code is at: lnykww/go-libp2p@7740e9b

UPDATE:
The demo code is at:lnykww/go-libp2p@87aa364

Details of the protocol:

1. if we communicate with peer is through relay. it means that peer or ourself is a private nat. so we use the relay connection establish as a event to do hole punching.
2. if we are public nat, we need do nothing, just wait for peer connect us.
3. if we are private nat, we need send packet to peer to create a new conntrack.

It doesn't support Symmetric NAT now. And it was test on Restrict NAT And Port Restrict NAT.

[lnykww]

What's the context for this? It needs a whole coordination protocol if we are to do hole punching, and I am not convinced a direct dial is the solution -- let alone that our current multistream protocol can't handle simultaneous open...

I believe this is just for "dial back". That is, if I'm NATed and I get an incoming connection via a relay, I can "dial back" to could a direct connection. However, I can't currently do that without closing the existing connection first. Ideally, I'd be able to create this new connection and then the swarm would prefer it for new streams (well, ideally we'd migrate...).

You are right. We have dialed using the listen port, so for hole punching, we just want both ends connect peer use ob addrs at same time.

And for quic reuse port, i will create a PR later.

[lnykww]

@Stebalien @vyzo @raulk
I have updated the PR, Request for a review. Thanks.

This PR, I add some interface let user can choose the best connection and best destination address.

[vyzo]

this seems incomplete. What are the actual implementations of these interfaces?

[lnykww]

this seems incomplete. What are the actual implementations of these interfaces?

@vyzo See this commit lnykww/go-libp2p@87aa364

It Implement the interface at Punch.go