WIP: Feat/memory transport

[pyropy]

Closes #2293

[MarcoPolo]

Friendly reminder to test your transport by adding a case here:

go-libp2p/p2p/test/transport/transport_test.go

Line 69 in 581571b

var transportsToTest = []TransportTestCase{

[pyropy]

Friendly reminder to test your transport by adding a case here:

go-libp2p/p2p/test/transport/transport_test.go

Line 69 in 581571b

var transportsToTest = []TransportTestCase{

Thanks, will add it.

Could you possibly take a look at this PR multiformats/go-multiaddr#256 ?

Edit: This is the issue I'm currently having while running my tests

Error:       Received unexpected error:
        	   failed to parse multiaddr "/memory/1234": unknown protocol memory

[pyropy]

I have few questions:

• When OpenStream is called on the Connection, how is the returned stream used? Is the AcceptStream called after OpenStream? My concern is about how the channels would be exchanged between the opened streams for the connection. I guess if OpenStream call is followed by AcceptStream we can send stream to "remote" connection.
• Should we keep using io.Pipe or switch it up with channels? I've seen that io.Pipe is using channels in the background.

[sukunrt]

When OpenStream is called on the Connection, how is the returned stream used? Is the AcceptStream called after OpenStream? My concern is about how the channels would be exchanged between the opened streams for the connection. I guess if OpenStream call is followed by AcceptStream we can send stream to "remote" connection.

OpenStream and AcceptStream happen on different libp2p hosts. Consider two hosts A and B. When A calls OpenStream, it creates a stream it can write to and read from. B will get this stream when it calls AcceptStream on the connection.
In the swarm, AcceptStream happens automatically because every open connection is waiting on AcceptStream here: https://github.com/libp2p/go-libp2p/blob/master/p2p/net/swarm/swarm_conn.go#L118
For implementing a transport, the transport should buffer streams till they are accepted by calling AcceptStream.

Should we keep using io.Pipe or switch it up with channels? I've seen that io.Pipe is using channels in the background.

I think io.Pipe is fine. This transport will only be used for tests, so it's nice to get as much of the work done by the stdlib as we can.

[pyropy]

I'm trying to get tests to pass they keep failing. For example, TestPing/Memory fails at protocol negotiation with either failed to negotiate protocol: io: read/write on closed pipe or failed to negotiate protocol: EOF. My guess is that it's failing at the stream level.

[sukunrt]

I think the tests are specifically failing because you don't support deadlines and basic_host expects deadline support. https://github.com/libp2p/go-libp2p/blob/master/p2p/host/basic/basic_host.go#L448

[sukunrt]

Write these before transport integration tests.

[sukunrt]

Write end to end transport tests here.