This extracts the routing package to its own repository
(https://github.com/ipfs/go-ipfs-routing). History has
been preserved. The new module has been gx'ed and published.
Imports have been rewritten and re-ordered accordingly.
An internal dependency to go-ipfs/repo has been removed
by substituting it with the go-datastore.Batching interface.
License: MIT
Signed-off-by: Hector Sanjuan <hector@protocol.ai>
Note: This commit is technically broken. However, I need to make a bunch of
cmds changes to make this work and I'd rather not bundle both changes into a
single commit.
License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
For the rest of the packages in util, move them to thirdparty
and update the references. util is gone!
License: MIT
Signed-off-by: Jeromy <jeromyj@gmail.com>
This lets FUSE mounts to track whether they are active or not by
tracking when fs.Serve terminates.
License: MIT
Signed-off-by: Stephen Whitmore <noffle@ipfs.io>
There is the following erreor otherwise:
```
$ go test github.com/ipfs/go-ipfs/fuse/ipns
../../fuse/ipns/ipns_test.go:116: not enough arguments in call to namesys.NewNameSystem
FAIL github.com/ipfs/go-ipfs/fuse/ipns [build failed]
```
License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
This allows direct access to the earlier protocol-specific Resolve
implementations. The guts of each protocol-specific resolver are in
the internal resolveOnce method, and we've added a new:
ResolveN(ctx, name, depth)
method to the public interface. There's also:
Resolve(ctx, name)
which wraps ResolveN using DefaultDepthLimit. The extra API endpoint
is intended to reduce the likelyhood of clients accidentally calling
the more dangerous ResolveN with a nonsensically high or infinite
depth. On IRC on 2015-05-17, Juan said:
15:34 <jbenet> If 90% of uses is the reduced API with no chance to
screw it up, that's a huge win.
15:34 <wking> Why would those 90% not just set depth=0 or depth=1,
depending on which they need?
15:34 <jbenet> Because people will start writing `r.Resolve(ctx, name,
d)` where d is a variable.
15:35 <wking> And then accidentally set that variable to some huge
number?
15:35 <jbenet> Grom experience, i've seen this happen _dozens_ of
times. people screw trivial things up.
15:35 <wking> Why won't those same people be using ResolveN?
15:36 <jbenet> Because almost every example they see will tell them to
use Resolve(), and they will mostly stay away from ResolveN.
The per-prodocol versions also resolve recursively within their
protocol. For example:
DNSResolver.Resolve(ctx, "ipfs.io", 0)
will recursively resolve DNS links until the referenced value is no
longer a DNS link.
I also renamed the multi-protocol ipfs NameSystem (defined in
namesys/namesys.go) to 'mpns' (for Multi-Protocol Name System),
because I wasn't clear on whether IPNS applied to the whole system or
just to to the DHT-based system. The new name is unambiguously
multi-protocol, which is good. It would be nice to have a distinct
name for the DHT-based link system.
Now that resolver output is always prefixed with a namespace and
unprefixed mpns resolver input is interpreted as /ipfs/,
core/corehttp/ipns_hostname.go can dispense with it's old manual
/ipfs/ injection.
Now that the Resolver interface handles recursion, we don't need the
resolveRecurse helper in core/pathresolver.go. The pathresolver
cleanup also called for an adjustment to FromSegments to more easily
get slash-prefixed paths.
Now that recursive resolution with the namesys/namesys.go composite
resolver always gets you to an /ipfs/... path, there's no need for the
/ipns/ special case in fuse/ipns/ipns_unix.go.
Now that DNS links can be things other than /ipfs/ or DHT-link
references (e.g. they could be /ipns/<domain-name> references) I've
also loosened the ParsePath logic to only attempt multihash validation
on IPFS paths. It checks to ensure that other paths have a
known-protocol prefix, but otherwise leaves them alone.
I also changed some key-stringification from .Pretty() to .String()
following the potential deprecation mentioned in util/key.go.
- updated go-ctxgroup and goprocess
ctxgroup: AddChildGroup was changed to AddChild. Used in two files:
- p2p/net/mock/mock_net.go
- routing/dht/dht.go
- updated context from hg repo to git
prev. commit in hg was ad01a6fcc8a19d3a4478c836895ffe883bd2ceab. (context: make parentCancelCtx iterative)
represents commit 84f8955a887232b6308d79c68b8db44f64df455c in git repo
- updated context to master (b6fdb7d8a4ccefede406f8fe0f017fb58265054c)
Aaron Jacobs (2):
net/context: Don't accept a context in the DoSomethingSlow example.
context: Be clear that users must cancel the result of WithCancel.
Andrew Gerrand (1):
go.net: use golang.org/x/... import paths
Bryan C. Mills (1):
net/context: Don't leak goroutines in Done example.
Damien Neil (1):
context: fix removal of cancelled timer contexts from parent
David Symonds (2):
context: Fix WithValue example code.
net: add import comments.
Sameer Ajmani (1):
context: fix TestAllocs to account for ints in interfaces
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
