P2P handshake handling

[prestonvanloon]

The basic idea of this PR is to implement the following:

On new peer connection, send a "handshake" message to the peer. The peer should also respond with a "handshake" message. If the two peers do not agree on some of the information in the handshake, they should disconnect and not try to reconnect with each other.

Banning peers is blocked by libp2p/go-libp2p#274

[codecov]

Codecov Report

Merging #2306 into master will decrease coverage by 0.18%.
The diff coverage is 52.88%.

@@            Coverage Diff             @@
##           master    #2306      +/-   ##
==========================================
- Coverage   65.81%   65.63%   -0.19%     
==========================================
  Files         119      122       +3     
  Lines        9446     9532      +86     
==========================================
+ Hits         6217     6256      +39     
- Misses       2538     2575      +37     
- Partials      691      701      +10

[raulk]

Hey @prestonvanloon, this usage of the libp2p API is not correct, that's why you're observing weird effects. The job of the connection manager is to keep the connection count in check to avoid killing commercial routers.

What you want to do is attach your notifiee directly to the host's network:

host.Network().Notify(...)

You can:

1. pass in a custom struct that implements the inet.Notifiee interface, or
2. use the convenience struct NotifyBundle; it wrongly resides in go-libp2p-connmgr right now, but is being hoisted to go-libp2p-core soon as part of Consolidate libp2p abstractions and core types libp2p/go-libp2p#602.

Once you do that, here's the key: you want to open the stream via the host itself (host.NewStream(peer, protocol)), not through the conn.

The conn doesn't know about multistream negotiation, and will open a raw stream for you but will not negotiate the protocol. The call to SetProtocol(string) won't kick off that negotiation either, that's actually an internal API that has, unfortunately, leaked to the user API.

So the result is that you have a raw stream with no protocol pinned on it on the wire, therefore the other end doesn't notify the stream handler for that protocol.

I'm sorry our APIs are a bit messy here. I'm taking this issue as an experience report and once we settle the core refactor, we'll embark on a mission to make our APIs more cohesive and intuitive.

[prestonvanloon]

@raulk, this is blocking / never opens the stream. Am I missing something?

[raulk]

Could you try to create the stream in a goroutine? "never block the callback" is the problem I think you're seeing here.

[prestonvanloon]

That works, thanks!

[prestonvanloon]

Thanks for the feedback @raulk. I'm still unable to create a stream between the peers. I'm seeing that host.NewStream is blocking indefinitely on both sides.