Alright, i think this would be really fun to have merged in.

Heres what I see us possibly doing: We add a config field value or daemon flag for ipfs experimental or ipfs exp. When the flag is enabled, this command gets added under ipfs exp corenet. We should also make it clear in the ipfs exp helptext that commands under it are there solely for experimentation and should not be depended on as they can and will change with a good deal of frequency.

The tests are failing because you have the wrong gx import paths, you can use gx deps find go-libp2p-peerstore to check what the right value is for those.

@whyrusleeping they are now failing because of that as HEAD changed dep.
@magik6k can you update it.

I'm pretty happy with this. Will need to run the idea by @jbenet, but this is a pretty cool thing to have (even if its just an experiment)

Error from teamcity:

[19:41:18][Step 4/4] Listening on [0.0.0.0] (family 0, port 10002)
[19:41:18][Step 4/4] expecting success: 
[19:41:18][Step 4/4]   ipfsi 1 exp corenet dial $PEERID_0 /ip4/127.0.0.1/tcp/10002 corenet-test
[19:41:18][Step 4/4] Listening on [0.0.0.0] (family 0, port 10001)
[19:41:18][Step 4/4] 
[19:41:18][Step 4/4] Error: protocol not supported
[19:41:18][Step 4/4] Dial for server to client
[19:41:18][Dial for server to client] Dial for server to client
[19:41:18][Step 4/4] not ok 11 - Dial for server to client
[19:41:18][Step 4/4] #  
[19:41:18][Step 4/4] #    ipfsi 1 exp corenet dial $PEERID_0 /ip4/127.0.0.1/tcp/10002 corenet-test
[19:41:18][Step 4/4] #  
[19:41:18][Step 4/4] 
[19:41:18][Step 4/4] expecting success: 
[19:41:18][Step 4/4]   kill $LISTENER_PID_PID &&
[19:41:18][Step 4/4]   wait $NC_SERVER_PID $NC_CLIENT_PID
[19:41:18][Step 4/4] 
[19:50:14][Step 4/4] The build go-ipfs::ci_tests_linux #3362 {buildId=5603} has been running for more than 15 minutes. Terminating...
[19:50:14][Step 4/4] Dumping threads before termination:

Circle is having different errors, something about wrong usage of netcat.

This is a cool idea, lemme review the interface when I'm back on land.

Btw finding a solid way to do this for libp2p would be ideal, and go-ipfs
could inherit the behavior.

Btw, @magik6k check out the plans over at https://github.com/ipfs/xtp --
it's a subproject we want to do. these interfaces MAY be able to relate.
On Tue, Sep 6, 2016 at 9:23 PM Jakub Sztandera notifications@github.com
wrote:

Circle is having different errors, something about wrong usage of netcat.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#3128 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcoaFyBzDAOfuyYd9GKuqhb7tYWBZSks5qnbvngaJpZM4JuIuh
.

I'll take a look at these test failures when i get a chance. I want to try and get this in (at least as an experimental feature)

I think we should have the ability for a dial out to setup a local listening port, so client software can connect to it like it would a remote service. The current method requires apps to be listening on both sides, no matter whether it's a listen or a dial call.

Attached my patch
dial-listen-.txt

Closing as #3943 got merged