GitLab

@jbenet @whyrusleeping

the next commit will change bitswap.Network.FindProviders to only deal
with IDs

cc @whyrusleeping

This reverts commit bf88f1aec5e3d397f97d64de52b52686cc7a8c8f.

Had to change the network interface from DialPeer(peer.ID) to
DialPeer(peer.PeerInfo), so that addresses of a provider are
handed to the network.

@maybebtc and I are discussing whether this should go all the
way down to the network, or whether the network _should always
work_ with just an ID (which means the network needs to be
able to resolve ID -> Addresses, using the routing system.
This latter point might mean that "routing" might need to
break down into subcomponents. It's a bit sketchy that
the Network would become smarter than just dial/listen and
I/O, but maybe there's a distinction between net.Network,
and something like a peernet.Network that has routing
built in...)

https://build.protocol-dev.com/job/race/9352/console

@jbenet @whyrusleeping

pinging you guys to spread awareness about the delay.D type for
configurable delays

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

this is a major refactor of the entire codebase
it changes the monolithic peer.Peer into using
a peer.ID and a peer.Peerstore.

Other changes:
- removed handshake3.
-	testutil vastly simplified peer
-	secio bugfix + debugging logs
-	testutil: RandKeyPair
-	backpressure bugfix: w.o.w.
-	peer: added hex enc/dec
-	peer: added a PeerInfo struct
  PeerInfo is a small struct used to pass around a peer with
 	a set of addresses and keys. This is not meant to be a
 	complete view of the system, but rather to model updates to
 	the peerstore. It is used by things like the routing system.
-	updated peer/queue + peerset
-	latency metrics
-	testutil: use crand for PeerID gen
 	RandPeerID generates random "valid" peer IDs. it does not
 	NEED to generate keys because it is as if we lost the key
 	right away. fine to read some randomness and hash it. to
 	generate proper keys and an ID, use:
 	  sk, pk, _ := testutil.RandKeyPair()
 	  id, _ := peer.IDFromPublicKey(pk)
 	Also added RandPeerIDFatal helper
- removed old spipe
- updated seccat
- core: cleanup initIdentity
- removed old getFromPeerList

addresses...

https://github.com/jbenet/go-ipfs/pull/438/files#r21878994

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

@whyrusleeping may wanna have a look and make sure i didn't screw
anything up here

BenchmarkInstantaneousAddCat1MB-4            200          10763761 ns/op
97.42 MB/s
BenchmarkInstantaneousAddCat2MB-4       panic: runtime error: invalid
memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0xbedd]

goroutine 14297 [running]:
github.com/jbenet/go-ipfs/exchange/bitswap/decision.(*taskQueue).Remove(0xc2087553a0,
        0xc2085ef200, 0x22, 0x56f570, 0xc208367a40)
    /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/decision/taskqueue.go:66
    +0x82
github.com/jbenet/go-ipfs/exchange/bitswap/decision.(*Engine).MessageSent(0xc20871b5c0,
        0x56f570, 0xc208367a40, 0x570040, 0xc208753d40, 0x0, 0x0)
    /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/decision/engine.go:177
    +0x29e
github.com/jbenet/go-ipfs/exchange/bitswap.(*bitswap).send(0xc20871b7a0,
        0x56f4d8, 0xc208379800, 0x56f570, 0xc208367a40,
        0x570040, 0xc208753d40, 0x0, 0x0)
    /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/bitswap.go:352
    +0x11c
github.com/jbenet/go-ipfs/exchange/bitswap.(*bitswap).taskWorker(0xc20871b7a0,
        0x56f4d8, 0xc208379800)
    /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/bitswap.go:238
    +0x165
    created by
    github.com/jbenet/go-ipfs/exchange/bitswap.New
    /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/bitswap.go:66
    +0x49e

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

in many places, entries are assigned from one slice to another and in
different goroutines. In one place, entries were modified (in the
queue). To avoid shared mutable state, probably best to handle entries
by value.

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

addresses https://github.com/jbenet/go-ipfs/pull/438#discussion_r21953742

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

only sort SortedEntries()

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

this opens up the possibility of having multiple queues. And for all
outgoing messages to be managed by the decision engine

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

bitswap keeps the threadsafe version. observing the ledger shows that it
doesn't need it anymore (ledgermanager is protected and safe).

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

If we put the lock next to the fields it protects, it can sometimes make
it easier to reason about threadsafety.

In this case, it reveals that the task queue (not threadsafe) isn't protected by the
mutex, yet shared between the worker and callers.

@whyrusleeping

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

it's only used in two places, but i think we've been using maps on IPFS
types so much now that the specificity is no longer necessary

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

Before, priority carried two pieces of information.

One: priority as defined by remote peer
Two: whether task is trashed

This assumes the protocol is defined for natural numbers instead of
integers. That may not always be the case. Better to leave that
assumption outside so this package isn't coupled to the whims of the
protocol.

The protocol may be changed to allow any integer value to be used.
Hopefully by that time, new responsibilties weren't added to the
Priority variable.

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

it seems to make sense since, in each place, the Key and Priority
represent the same information

b/c you know the saying...

"It is better to have 100 functions operate on one data structure than
10 functions on 10 data structures."

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>