[WIP] feat: implement relay circuit

[dryajov]

Depends on this PRs:

• feat: expose utils multiformats/js-multistream-select#37
• feat: adding circuit addresses multiformats/js-mafmt#14
• [WIP] feat: adding p2p-circuit proto multiformats/js-multiaddr#41
• [WIP] feat: adding relay js-libp2p-switch#181
• [WIP] feat: adding relay js-libp2p#59

[RichardLitt]

Needs README?

[dryajov]

@RichardLitt I think it does, and I have a stub in the PR, I belive?

I'm just getting acquainted with the dev cycle/practices, so please feel free to point out whenever something is off :).

As a suggestion, can we get a link to the contrib guidelines in every relevant README? That would make things a lot easier - ignore this, if they are already there, I might have simply missed them.

Also, if you have links/info of things that I should review regarding the above, please do link them here.

[RichardLitt]

@dryajov There is a stub, but I think a bit more would be great. Here is an example libp2p README template: ipfs/community#242.

[dryajov]

@diasdavid @dignifiedquire @lgierth

This should be implemented to the point were messages are being passed from the src to the dest peers over the relay. I think this is a good starting point and is ready for some review. I'd like to get as much feedback as possible before continuing, maybe some discussion around whats next is in order. I'll try to make it to the standup call tomorrow, but can't promise anything.

[daviddias]

@dryajov as we talked over IRC, I'm catching up with all the things, nevertheless, thank you so much for investing time into this.

I need to double check here a couple of things:

• Has there been any decision on how to enable a Node to become a relay node? Perhaps by having a flag in the config?
• Is there a test being added libp2p-ipfs-nodejs that shows how all of this got integrated?

[dryajov]

@diasdavid

• I remember seeing some mentions (tho would have to search for the issue) regarding this being controlled by a config value and was planing on adding it once I start integrating things.
• Have not yet added any tests to libp2p-ipfs-node, but working on functional/unit tests in libp2p-circuit itself.

[ghost]

Yes the config option would control whether to relay connections for other nodes.

I imagine there could also be an option that enables constructing relay addrs for nodes which we don't have a usable address for. For example, in a browser environment, if we only know an /ip4/tcp address for a node we want to connect to, we'd take the /ipfs part form that (or soon /p2p) and make a /p2p-circuit addr from it. This part could also happen unconditionally though. The peerstore/peerbook would automatically add a /p2p-circuit addr for any peer it knows.

[dryajov]

@lgierth @diasdavid @dignifiedquire

Just a small update on where I'm at with this.

I've started reworking the dialer/listener parts as a transport. The dialer/listener take the swarm now and uses that to dial on the underlying low level transport, the listener is enabled in a similar way to identify with the relay method called from libp2p, which is what sets the relay flag in swarm and registers the listener.

This is a pretty rough WIP so far, and I understand that some of the integration points are probably wrong, partly because there doesn't seem to be a good mechanism for registering handlers that use the swarm such as identify or ping, partly because I'm still mulling over the architecture/design. That said, I think this is a good point to start a discussion/review of what I have, so that I don't get too far along on the wrong path.

Now, the fun part :)

It's possible that I'm doing something completely wrong, but I'm running into what seems to be a spdy/zlib issue. I'm running the simplest test, where I dial a peer B from peer A over the relay, but I'm running into an odd issue. Basically, I can see the relay being successfully negotiated up until the point where the swarm tries to use the relayed connection and sends a multistream header, after which Zlib throws:

Uncaught Error: incorrect header check
at Zlib._handle.onerror (zlib.js:370:17)

Here is a complete log of the run:

https://gist.github.com/dryajov/df444fe00a51298c8ca772adc13926f5#file-circuit-log

I've traced it down to spdy, which is where zlib is throwing, but I couldn't say for sure since that is a native module, and I haven't had time to debug node itself just yet. For pointers, it seems to happen somewhere around spdy-transport/protocol/spdy/zlib-pool.js.

I'm guessing there are too many layers of encryption/multiplexing happening on the same channel, maybe I just need to skip the second multiplexing attempt on the same channel if the channel is already being multiplexed?

In any case, if anyone is willing to dig through this with me, I'm available and can jump online for a debugging session. One thing to keep in mind, all of this is running locally only, if you want to run it yourself you'd have to pull in the PRs listed in the first comment, and then link things locally, so, it might be easier to do on my box at this point.

[dryajov]

Small update on the issues I was running into above. There seem to be several possibly related issues going on at the same time, i'll try to list them bellow:

1. If I have a setup where I would have a node with both TCP and WS enabled, and I try to dial into that node from two distinct nodes, each running on either TCP or WS, if the TCP node dials first the WS node would get stuck and the stream would end abruptly for the WS node, however, if I dial in with the WS node first and TCP second, it works as expected under SPDY but not under libp2p-multiplex. This is unrelated to relay, since for that test I would have it disabled.
   1. This would manifest in different ways depending on the muxer I was using, SPDY would give me the zlib error.
   2. libp2p-multiplex would just end the stream and return true as the error the in multistream-select in decodeFromReader, and hang up in different places.
      • It doesn't seem that the order of dialing (TCP/WS or WS/TCP) fixes this issue tho, so it could be a different issue altogether.

This could be just issues with my environment, since I've got so many modules linked. I'll upload what I have so far so that someone else can play with it, just be warned things are really messy right now. Good thing is that I can start cleaning them up now and write some decent tests.

It's not fun to be stuck ;)