Feat/utp #1789

whyrusleeping · 2015-10-04T05:24:31Z

Implement utp support

whyrusleeping · 2015-10-04T05:24:44Z

still WIP btw

jbenet · 2015-10-04T06:43:21Z

exciting! 👍 👏

jbenet · 2015-10-04T10:22:52Z

p2p/net/conn/dial.go

+	useLocalAddr := true
+	for _, p := range raddr.Protocols() {
+		if p.Name == "utp" {
+			useLocalAddr = false


is this the lib problem? we need to fix it. in many situations people will not be able to open another port. they need to be able to specify the one port everything happens through.

jbenet · 2015-10-04T10:28:53Z

~~problem: just adding a utp addr doesn't work:~~ Fixed. wrong binary :/

> ipfs config Addresses.Swarm
[
  "/ip4/0.0.0.0/tcp/4001",
  "/ip4/0.0.0.0/udp/4003/utp"
]
> ipfs daemon
Initializing daemon...
Swarm listening on /ip4/10.0.1.12/tcp/4001
Swarm listening on /ip4/108.54.113.161/tcp/37304
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/127.94.0.1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/0.0.0.0/tcp/8080
Daemon is ready

no utp. :(

with debug logs i see:

DEBU[06:24:05:000] Config.Addresses.Swarm:[/ip4/0.0.0.0/tcp/4001 /ip4/0.0.0.0/udp/4003/utp]  module=core
DEBU[06:24:05:000] Config.Addresses.Swarm:[/ip4/0.0.0.0/tcp/4001] (filtered)  module=core

it's getting filtered out.

fixed. wrong binary. :(

jbenet · 2015-10-04T10:37:28Z

p2p/net/swarm/swarm_dial.go

@@ -305,7 +294,7 @@ func (s *Swarm) dial(ctx context.Context, p peer.ID) (*Conn, error) {
 	remoteAddrs = addrutil.Subtract(remoteAddrs, ila)
 	remoteAddrs = addrutil.Subtract(remoteAddrs, s.peers.Addrs(s.local))

-	log.Debugf("%s swarm dialing %s -- local:%s remote:%s", s.local, p, s.ListenAddresses(), remoteAddrs)
+	log.Errorf("%s swarm dialing %s -- local:%s remote:%s", s.local, p, s.ListenAddresses(), remoteAddrs)


this should stay as debug

no, its totally an error

this is a statement that is always executed. and it doesnt have an error, it's just informative. i already switched it back.

lol, i guess you missed the sarcasm. I'll use tags next time

jbenet · 2015-10-04T11:01:15Z

Perf is not good. i'm getting <1MB/s with ipfs cat on the same machine.

Also CPU is pegged and RAM is ~300MB, though the file is 200MB, and only have 50MB of it...

finished:

200.00 MB 4m20s

that's 0.77 MB/s

jbenet · 2015-10-04T11:23:39Z

in another run, with an isolated network of 5 nodes:

> IPFS_PATH=4 ipfs get -o r4 QmXipyrjt2Vzjg2vV7uhgCi8GNEFhrEdXrirtDcYhqGGEc
Saving file(s) to r4
200.00 MB 1m7s

but

> IPFS_PATH=2 ipfs cat QmXipyrjt2Vzjg2vV7uhgCi8GNEFhrEdXrirtDcYhqGGEc >r2

is just completely stuck. daemon responds to other queries though.

>  IPFS_PATH=2 ipfs id -f='<id>\n'
QmdpL8zu4GTPvse64R2LFrxDZRC9gnj8hvirfnwRq4q3Xs
> IPFS_PATH=2 ipfs bitswap stat
bitswap status
    provides buffer: 0 / 256
    blocks received: 1
    dup blocks received: 0
    dup data received: 0
    wantlist [5 keys]
        QmZymseMQJKLVmzx1W8GyKzUL1zcgF9NEXVAwTxnWvSVWS
        QmetGENiJ9YCUyUuYyJDpGHXLYichh9hqZnsBACqUaFc5F
        QmYVkwVgmtbWKdfAjNrVTbytaKUTF3ixXP5YbBMfHrhGQ6
        QmS3JfCbMmydsh1TtPiDGE39eimoP5nsej8JVjjjpEjcAp
        QmSgusHjqd3pT79FUWv8TmGwUWA2E4F4tHmBV5Dn7CbqhL
    partners [2]
        QmZtLnbWEnYyyNiVt7wobVdhXEPKxuhYEapPywF4zGbg59
        QmdTUjEc5UtJ97aMReJTYGqA2Uvp6LG5VEzxfxm2S3485b

(3) QmNRSUw5jiDmzb4xq33wgHC5acRibJ8kZiv6iUfnsfPBDb is creator.
(4) QmdTUjEc5UtJ97aMReJTYGqA2Uvp6LG5VEzxfxm2S3485b has it (one of the partners)

> IPFS_PATH=3 ipfs id -f='<id>\n'
QmNRSUw5jiDmzb4xq33wgHC5acRibJ8kZiv6iUfnsfPBDb
> IPFS_PATH=3 ipfs bitswap stat
bitswap status
    provides buffer: 0 / 256
    blocks received: 0
    dup blocks received: 0
    dup data received: 0
    wantlist [0 keys]
    partners [2]
        QmZtLnbWEnYyyNiVt7wobVdhXEPKxuhYEapPywF4zGbg59
        QmdTUjEc5UtJ97aMReJTYGqA2Uvp6LG5VEzxfxm2S3485b
> IPFS_PATH=4 ipfs id -f='<id>\n'
QmdTUjEc5UtJ97aMReJTYGqA2Uvp6LG5VEzxfxm2S3485b
> IPFS_PATH=4 ipfs bitswap stat
bitswap status
    provides buffer: 0 / 256
    blocks received: 1120
    dup blocks received: 314
    dup data received: 82317612
    wantlist [0 keys]
    partners [2]
        QmNRSUw5jiDmzb4xq33wgHC5acRibJ8kZiv6iUfnsfPBDb
        QmZtLnbWEnYyyNiVt7wobVdhXEPKxuhYEapPywF4zGbg59

so neither of these list (2) QmdpL8zu4GTPvse64R2LFrxDZRC9gnj8hvirfnwRq4q3Xs as a partner!

and yet they're all connected.

> IPFS_PATH=2 ipfs swarm peers
/ip4/10.0.1.12/udp/63558/utp/ipfs/QmZtLnbWEnYyyNiVt7wobVdhXEPKxuhYEapPywF4zGbg59
/ip4/127.0.0.1/udp/4100/utp/ipfs/QmTGQs7w852bh43JA44YKg2t3Gar4KRBk4fiswL9zgFXuj
/ip4/127.0.0.1/udp/63548/utp/ipfs/QmNRSUw5jiDmzb4xq33wgHC5acRibJ8kZiv6iUfnsfPBDb
/ip4/127.0.0.1/udp/63555/utp/ipfs/QmZtLnbWEnYyyNiVt7wobVdhXEPKxuhYEapPywF4zGbg59
/ip4/127.94.0.1/udp/63557/utp/ipfs/QmZtLnbWEnYyyNiVt7wobVdhXEPKxuhYEapPywF4zGbg59
/ip4/127.94.0.1/udp/63561/utp/ipfs/QmdTUjEc5UtJ97aMReJTYGqA2Uvp6LG5VEzxfxm2S3485b
> IPFS_PATH=3 ipfs swarm peers
/ip4/10.0.1.12/udp/4101/utp/ipfs/QmZtLnbWEnYyyNiVt7wobVdhXEPKxuhYEapPywF4zGbg59
/ip4/127.0.0.1/udp/4100/utp/ipfs/QmTGQs7w852bh43JA44YKg2t3Gar4KRBk4fiswL9zgFXuj
/ip4/127.0.0.1/udp/4102/utp/ipfs/QmdpL8zu4GTPvse64R2LFrxDZRC9gnj8hvirfnwRq4q3Xs
/ip4/127.0.0.1/udp/4104/utp/ipfs/QmdTUjEc5UtJ97aMReJTYGqA2Uvp6LG5VEzxfxm2S3485b
> IPFS_PATH=4 ipfs swarm peers
/ip4/127.0.0.1/udp/4100/utp/ipfs/QmTGQs7w852bh43JA44YKg2t3Gar4KRBk4fiswL9zgFXuj
/ip4/127.0.0.1/udp/63551/utp/ipfs/QmNRSUw5jiDmzb4xq33wgHC5acRibJ8kZiv6iUfnsfPBDb
/ip4/127.94.0.1/udp/4102/utp/ipfs/QmdpL8zu4GTPvse64R2LFrxDZRC9gnj8hvirfnwRq4q3Xs
/ip4/127.94.0.1/udp/63556/utp/ipfs/QmZtLnbWEnYyyNiVt7wobVdhXEPKxuhYEapPywF4zGbg59

this appears to be either bitswap being incredibly stupid, or the transport totally failing.

and yes, an iptb restart fixed the problem -- (2) succeeds. but the problem remains-- that shouldn't ever happen.

jbenet · 2015-10-04T11:24:47Z

in another run, stalled at 170MB for 20s, then finished.

anacrolix · 2015-10-05T01:18:07Z

Are the nodes that seem to stall, purely receiving at that time on utp. That is to say, are they only calling utp.Conn.Read? No writes?

whyrusleeping · 2015-10-05T03:48:42Z

@anacrolix There may be interleaved reads and writes. we do duplex communication over the same pipe

jbenet · 2015-10-05T03:51:25Z

@anacrolix no, they would be writing too, at least at some point. other things happening would cause samll amts of data to be written to all nodes (dht random queries for bootstrapping, bitswap wantlist updates, etc)

jbenet · 2015-10-05T03:51:36Z

this stalling may be more a problem in ipfs than in utp. i'm not sure.

whyrusleeping · 2015-10-05T05:55:30Z

p2p/net/conn/dial.go

@@ -265,3 +209,100 @@ func MultiaddrNetMatch(tgt ma.Multiaddr, srcs []ma.Multiaddr) ma.Multiaddr {
 	}
 	return nil
 }
+
+type ProtoDialer interface {


@jbenet I've taken and made the dialers an interface, just like you always wanted!

This might belong somewhere better than here though, and the interface probably could use some tweaks, but this is the composition that i'm wanting.

whyrusleeping · 2015-10-05T06:48:21Z

I added a utp option to iptb so you can easily generate a testnet using utp:

$ iptb init -n 10 --utp

whyrusleeping · 2015-10-06T03:54:56Z

@jbenet how did you set up the iptb cluster when you reproduced the hangs?

jbenet · 2015-10-06T07:00:48Z

@whyrusleeping i just set them up normally, and then changed all the addresses manually.

jbenet · 2015-10-06T07:00:59Z

they were all able to talk to each other though

whyrusleeping · 2015-10-06T16:12:06Z

so you set them to bootstrap to eachother?

jbenet · 2015-10-27T08:18:38Z

p2p/net/conn/transport.go

+	}
+
+	// get the local net.Addr manually
+	la, err := manet.ToNetAddr(laddr)


do this before the Listen. if errors, saves the listener. also this is currently wrong as the listener will not be closed if this errors here.

Also, i do not think the transport should start listening just by being created. reuseport should allow listening after, (yes after a dial has opened on the same port).

jbenet · 2015-10-27T08:47:03Z

License: MIT Signed-off-by: Jeromy <jeromyj@gmail.com>

whyrusleeping · 2015-10-28T21:31:50Z

@jbenet
#1789 (comment)
#1789 (comment)

We can call the things something other than transports. Otherwise, how do you want the interface to look?

whyrusleeping · 2015-10-29T00:08:14Z

@jbenet instead of going back and forth in comments for this, lets just have a hangout and hash it out

rht · 2015-11-25T00:23:35Z

It looks like the CR got stalled.

Will 0.4.0 ship first? The sooner this happens, the sooner pending modularizations (commands/files, gateway, go-libp2p, cmd/*) can happen? Even if modularization is bottlenecked by gx pathing, this has still smaller decision tree than utp interface's?

jbenet · 2015-11-25T00:37:39Z

I think we did hash it out-- just needs rebasing over the new transports?

whyrusleeping · 2015-11-25T03:07:51Z

yeah, this is going to go into libp2p, i have a PR ready, doesnt look like i've pushed it yet.

rht · 2015-11-25T03:58:45Z

Which means, the remaining bottleneck for 0.3.10 is ipfs-update?

whyrusleeping · 2015-11-25T07:54:34Z

yeap. ipfs-update is all thats in the way of 0.3.10. i'm pushing pretty much everything else into 0.4.0

jbenet added the status/in-progress In progress label Oct 4, 2015

ghost mentioned this pull request Oct 4, 2015

Sprint Sep 28 ipfs/team-mgmt#35

Closed

88 tasks

jbenet reviewed Oct 4, 2015
View reviewed changes

whyrusleeping force-pushed the feat/utp branch from 657809f to d3e9792 Compare October 4, 2015 18:59

whyrusleeping mentioned this pull request Oct 4, 2015

throughput is 5 MB/s on loopback anacrolix/utp#3

Closed

whyrusleeping force-pushed the feat/utp branch from d3e9792 to 128624a Compare October 4, 2015 19:18

whyrusleeping force-pushed the feat/utp branch 2 times, most recently from 430b9df to e75c69a Compare October 5, 2015 05:41

whyrusleeping reviewed Oct 5, 2015
View reviewed changes

whyrusleeping force-pushed the feat/utp branch from e75c69a to 7177615 Compare October 5, 2015 06:18

whyrusleeping force-pushed the feat/utp branch from 7177615 to 1169398 Compare October 5, 2015 06:49

whyrusleeping force-pushed the feat/utp branch from 8c59200 to 096f5ca Compare October 6, 2015 04:09

whyrusleeping force-pushed the feat/utp branch from df5677b to 4be92ef Compare October 20, 2015 05:51

RichardLitt mentioned this pull request Oct 22, 2015

Sprint Oct 19th ipfs/team-mgmt#40

Closed

35 tasks

jbenet reviewed Oct 27, 2015
View reviewed changes

vendor in utp code

5eb6eec

License: MIT Signed-off-by: Jeromy <jeromyj@gmail.com>

whyrusleeping force-pushed the feat/utp branch 2 times, most recently from 860b5ca to c1ef091 Compare October 28, 2015 04:02

whyrusleeping removed the RFCR label Oct 28, 2015

whyrusleeping force-pushed the feat/utp branch from c1ef091 to f1dbbed Compare October 28, 2015 17:07

implement basic utp dialing and listening support

9b76adc

License: MIT Signed-off-by: Jeromy <jeromyj@gmail.com>

whyrusleeping force-pushed the feat/utp branch from f1dbbed to 9b76adc Compare October 28, 2015 21:07

whyrusleeping mentioned this pull request Nov 2, 2015

Sprint Oct 26 ipfs/team-mgmt#41

Closed

47 tasks

whyrusleeping closed this Dec 9, 2015

jbenet removed the status/in-progress In progress label Dec 9, 2015

Kubuxu deleted the feat/utp branch February 27, 2017 20:38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat/utp #1789

Feat/utp #1789

whyrusleeping commented Oct 4, 2015

whyrusleeping commented Oct 4, 2015

jbenet commented Oct 4, 2015

jbenet Oct 4, 2015

jbenet commented Oct 4, 2015

jbenet Oct 4, 2015

whyrusleeping Oct 5, 2015

jbenet Oct 5, 2015

whyrusleeping Oct 5, 2015

jbenet commented Oct 4, 2015

jbenet commented Oct 4, 2015

jbenet commented Oct 4, 2015

anacrolix commented Oct 5, 2015

whyrusleeping commented Oct 5, 2015

jbenet commented Oct 5, 2015

jbenet commented Oct 5, 2015

whyrusleeping Oct 5, 2015

whyrusleeping Oct 5, 2015

whyrusleeping commented Oct 5, 2015

whyrusleeping commented Oct 6, 2015

jbenet commented Oct 6, 2015

jbenet commented Oct 6, 2015

whyrusleeping commented Oct 6, 2015

jbenet Oct 27, 2015

jbenet Oct 27, 2015

jbenet commented Oct 27, 2015

whyrusleeping commented Oct 28, 2015

whyrusleeping commented Oct 29, 2015

rht commented Nov 25, 2015

jbenet commented Nov 25, 2015

whyrusleeping commented Nov 25, 2015

rht commented Nov 25, 2015

whyrusleeping commented Nov 25, 2015

Feat/utp #1789

Feat/utp #1789

Conversation

whyrusleeping commented Oct 4, 2015

whyrusleeping commented Oct 4, 2015

jbenet commented Oct 4, 2015

Choose a reason for hiding this comment

jbenet commented Oct 4, 2015

fixed. wrong binary. :(

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jbenet commented Oct 4, 2015

jbenet commented Oct 4, 2015

jbenet commented Oct 4, 2015

anacrolix commented Oct 5, 2015

whyrusleeping commented Oct 5, 2015

jbenet commented Oct 5, 2015

jbenet commented Oct 5, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

whyrusleeping commented Oct 5, 2015

whyrusleeping commented Oct 6, 2015

jbenet commented Oct 6, 2015

jbenet commented Oct 6, 2015

whyrusleeping commented Oct 6, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jbenet commented Oct 27, 2015

whyrusleeping commented Oct 28, 2015

whyrusleeping commented Oct 29, 2015

rht commented Nov 25, 2015

jbenet commented Nov 25, 2015

whyrusleeping commented Nov 25, 2015

rht commented Nov 25, 2015

whyrusleeping commented Nov 25, 2015