Trying to talk to legacy js & go IPFS mDNS implementations

[gnunicorn]

as reported in #233

discover over mDNS:

• (latest) jsipfs
• (latest) ipfs-go

---

It is currently not in the scope, that these can discover us (as we are unsure their messages apply to the standard). However, they still might ;) .

[gnunicorn]

@dvc94ch this now discovers both legacy ipfs-go and ipfs-js implementations and returns proper multiaddrs for them (example client1 shows dialing XYZ, here, too). It requires a small patch on the ipfs-side and I am not able they ever actually connected... Maybe you want to try it, this is the change required...

diff --git i/src/p2p/behaviour.rs w/src/p2p/behaviour.rs
index 2a47c45..d9e972e 100644
--- i/src/p2p/behaviour.rs
+++ w/src/p2p/behaviour.rs
@@ -90,7 +90,7 @@ impl<TSubstream: AsyncRead + AsyncWrite, TSwarmTypes: SwarmTypes> Behaviour<TSub
     pub fn new(options: SwarmOptions<TSwarmTypes>, repo: TSwarmTypes::TRepo) -> Self {
         info!("Local peer id: {}", options.peer_id.to_base58());
 
-        let mdns = Mdns::new().expect("Failed to create mDNS service");
+        let mdns = Mdns::new_with_legacy().expect("Failed to create mDNS service");
 
         let mut kademlia = Kademlia::new(options.peer_id.to_owned());
         for (addr, peer_id) in &options.bootstrap {

[gnunicorn]

I don't think these changes are still needed.

[dvc94ch]

Mmh, I can't get it to work. The jsipfs node worked fine when it discovered the rust-ipfs node.

Working scenario:
js-ipfs discovers rust-ipfs
js-ipfs connects to rust-ipfs
rust-ipfs send-wantlist to js-ipfs
js-ipfs send-block to rust-ipfs

Scenario that doesn't work
rust-ipfs discovers js-ipfs
rust-ipfs connects to js-ipfs
nothing happens

js-ipfs never receives a libp2p connect event.

[gnunicorn]

js-ipfs discovers rust-ipfs

This works? Curious, because we aren't actually sending any js-ipfs-style discovery-responses.

rust-ipfs connects to js-ipfs
nothing happens

js-ipfs never receives a libp2p connect event.

What is the code you are using? And how are you determining whether the js-ipfs ever received the event?

[dvc94ch]

This works? Curious, because we aren't actually sending any js-ipfs-style discovery-responses.

Sorry for being unclear, it works iff u patch it to work [0].

What is the code you are using? And how are you determining whether the js-ipfs ever received the event?

diff --git a/src/core/components/libp2p.js b/src/core/components/libp2p.js
index c45b65f..5b4e286 100644
--- a/src/core/components/libp2p.js
+++ b/src/core/components/libp2p.js
@@ -40,7 +40,10 @@ module.exports = function libp2p (self, config) {
     }
   })
 
-  libp2p.on('peer:connect', peerInfo => peerBook.put(peerInfo))
+  libp2p.on('peer:connect', (peerInfo) => {
+    console.log(peerInfo)
+    return peerBook.put(peerInfo)
+  })
 
   return libp2p
 }

• [0] https://github.com/dvc94ch/js-libp2p-mdns

[gnunicorn]

your latest master (with my branch) doesn't work for me at all. the background thread dies with:

$ cargo +nightly run --example client1 
    Finished dev [unoptimized + debuginfo] target(s) in 0.72s
     Running `target/debug/examples/client1`
[2019-02-26T09:52:11Z INFO  ipfs::p2p::behaviour] Local peer id: QmS1CGvbfvZ6iWGddsvCpGiADSD4kQe7MpKdCaZKrsoFkr
[2019-02-26T09:52:12Z INFO  ipfs::p2p] Listening on "/ip4/127.0.0.1/tcp/40199"
thread 'tokio-runtime-worker-0' panicked at 'not yet implemented: async-await-preview currently only supports futures 0.1. Use the compatibility layer of futures 0.3 instead, if you want to use futures 0.3.', /home/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-async-await-0.1.6/src/compat/backward.rs:76:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[2019-02-26T09:52:12Z INFO  ipfs::p2p::behaviour] Providing block QmRQKDyEycNmMAWUVXUPdWJXLuWwPwLJCXavpSkUZoX3HR
[2019-02-26T09:52:12Z INFO  ipfs::p2p::behaviour] Want block QmVNrZhKw9JwYa4YPEZVccQxfgQJq993yP78QEN28927vq
[2019-02-26T09:52:12Z INFO  ipfs::p2p::behaviour] kad: Could not find provider for QmVNrZhKw9JwYa4YPEZVccQxfgQJq993yP78QEN28927vq

but also under my previous version, I didn't see any network traffic happening between the nodes after the rust ipfs telling me "queuing dialing".

[dvc94ch]

Sorry about that, I haven't pushed the change yet.

git diff src/future.rs
diff --git a/src/future.rs b/src/future.rs
index 270275a..858bafb 100644
--- a/src/future.rs
+++ b/src/future.rs
@@ -32,6 +32,8 @@ impl<TBlockStore: BlockStore> Future for BlockFuture<TBlockStore> {
             Poll::Ready(Ok(None)) => {
                 let future = self.block_store.get(self.cid.clone());
                 self.get_mut().future = future;
+                tokio::prelude::task::current().notify();
+                //waker.wake();
                 Poll::Pending
             },
             Poll::Ready(Err(err)) => {

[dvc94ch]

but also under my previous version, I didn't see any network traffic happening between the nodes after the rust ipfs telling me "queuing dialing".

The poll function then returns the DialPeer event that was queued and the Swarm should do the connecting. I still haven't figured the problem out yet, but I appreciate your time and input on this.

[tomaka]

Relevant: libp2p/specs#80 (comment)