[feature request] Could you add a "port forwarding" example?

[diyism]

Could you do me a favor to add a "port forwarding" example?
Currently only there is a "http-proxy" example(https://github.com/libp2p/go-libp2p/tree/master/examples/http-proxy)
If we have "port forwarding" example, we can port-forward to any service port, for example sniproxy, nginx etc.

Edit:
#324 (comment)

[diyism]

There is one example based on ZeroTier: https://github.com/selvakn/p2p-port-forward

But p2p-port-forward sometimes crash with "double free or corruption (fasttop)".

[diyism]

There is one based on Tox: https://github.com/gjedeer/tuntox
But tuntox sometimes won't traverse the NAT (for example, one side:Port Restricted Cone and the other side: Open)

[hsanjuan]

Hey @diyism , it should be pretty straight forward to port-forward (or tunnel) something using https://github.com/hsanjuan/go-libp2p-gostream

Just like they do here: https://zupzup.org/go-port-forwarding/ but using the Dial and Listen provided by go-libp2p-gostream as you see fit. i.e.:

Client

standard tcp listener accepts connection-A
gostream dialer provides connection-B to destination peer
forwarder copies A-to-B

Server

gostream Listen accepts connection C from client
standard tcp dialer opens connection D to tcp destination
forwarder copies  C-to-D

Hope it helps

[diyism]

IPFS has experimental commands to tunnel tcp stream:
"ipfs p2p listener open" and "ipfs p2p stream dial"

ipfs/kubo#3397 (comment)

If the IPFS peer tcp tunnel can be built on go-libp2p-kcp finally, the tunnel will be perfect in performance:
paralin/go-libp2p-kcp#1

[diyism]

What a pity, ipfs p2p TCP tunnel breaks after every request: ipfs/kubo#5032

[Stebalien]

It's being fixed: ipfs/kubo#4929

[Stebalien]

We're also going to start work on a libp2p "daemon" in the near future so you don't have to run a full go-ipfs node.

[diyism]

$ ipfs version
ipfs version 0.12.1
ipfs id       # get the server ipfs peer id

#server side( oracle VPS in south korea):
ipfs config --json Experimental.Libp2pStreamMounting true
while true; do nohup /usr/bin/ssh -o ServerAliveInterval=10 -o ServerAliveCountMax=6 -CND 127.0.0.1:8081 127.0.0.1 >/dev/null 2>&1; sleep 1; done &
ipfs p2p listen /x/my-p2p/1 /ip4/127.0.0.1/tcp/8081

#client side (china shanghai home):
ipfs config --json Experimental.Libp2pStreamMounting true
ipfs p2p forward /x/my-p2p/1 /ip4/127.0.0.1/tcp/18081 /p2p/<server ipfs peer id>
time curl --socks5 127.0.0.1:18081 https://www.google.com/ncr
real	0m2.238s
user	0m0.025s
sys	0m0.013s

Great, "ipfs p2p forward" works very well in ipfs v0.12.1 now.
tested in china, the band width is about 0.5MB/s while the naive proxy (to the same server) is 5MB/s

[Winterhuman]

@diyism You might want to check out the performance compared to https://github.com/hyprspace/hyprspace, they had an update which significantly boosted bandwidth performance which would be good to compare against ipfs p2p.

[diyism]

@diyism You might want to check out the performance compared to https://github.com/hyprspace/hyprspace, they had an update which significantly boosted bandwidth performance which would be good to compare against ipfs p2p.

I've tested hyperspace, its bandwith is about 0.6MB/s from china to southkorea, it's same to the bandwidth of "ipfs p2p forwarding", so currently, it seems there's no advantage compared to ipfs p2p currently.

[Winterhuman]

Ah I see, seems ipfs p2p does the Hyprspace optimisations already then, thanks for confirming regardless!