- 23 Dec, 2014 5 commits
-
-
Brian Tiger Chow authored
-
Brian Tiger Chow authored
-
Brian Tiger Chow authored
This reverts commit bf88f1aec5e3d397f97d64de52b52686cc7a8c8f.
-
Juan Batiz-Benet authored
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...)
-
Juan Batiz-Benet authored
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
-
- 16 Dec, 2014 1 commit
-
-
Juan Batiz-Benet authored
-
- 05 Dec, 2014 2 commits
- 15 Nov, 2014 3 commits
-
-
Brian Tiger Chow authored
-
Brian Tiger Chow authored
remove 'adapter' concept instead, describe the component as the bitswap network it's still an adapter, but it's just not necessary to describe it as such
-
Brian Tiger Chow authored
-
- 05 Nov, 2014 2 commits
-
-
Brian Tiger Chow authored
-
Brian Tiger Chow authored
-
- 26 Oct, 2014 1 commit
-
-
Jeromy authored
-
- 25 Oct, 2014 1 commit
-
-
Jeromy authored
-
- 20 Oct, 2014 1 commit
-
-
Juan Batiz-Benet authored
![](http://m.memegen.com/77n7dk.jpg)
-
- 18 Oct, 2014 2 commits
-
-
Juan Batiz-Benet authored
-
Juan Batiz-Benet authored
Important bugfix. Otherwise bitswap cannot message peers the node has not connected to yet :(
-
- 11 Oct, 2014 1 commit
-
-
Juan Batiz-Benet authored
new Service interface
-
- 25 Sep, 2014 2 commits
-
-
Brian Tiger Chow authored
-
Brian Tiger Chow authored
Rather than pushing errors back down to lower layers, propagate the errors upward. This commit adds a `ReceiveError` method to BitSwap's network receiver. Still TODO: rm the error return value from: net.service.handler.HandleMessage This is inspired by delegation patterns in found in the wild.
-
- 22 Sep, 2014 2 commits
-
-
Brian Tiger Chow authored
style(exch:bitswap) rename NetMessage adapter impl
-
Brian Tiger Chow authored
Move go-ipfs/bitswap package to go-ipfs/exchange/bitswap * Delineates the difference between the generic exchange interface and implementations (eg. BitSwap protocol) Thus, the bitswap protocol can be refined without having to overthink how future exchanges will work. Aspects common to BitSwap and other exchanges can be extracted out to the exchange package in piecemeal. Future exchange implementations can be placed in sibling packages next to exchange/bitswap. (eg. exchange/multilateral)
-