- 10 Jun, 2020 2 commits
-
-
Ivan Vandot authored
-
Janoš Guljaš authored
Co-authored-by:
svetomir <svetomirsmiljkovic@gmail.com>
-
- 09 Jun, 2020 3 commits
-
-
Zahoor Mohamed authored
* Local pinning fix
-
Zahoor Mohamed authored
* remove tag address field for bzz-chunk api * Remove api and functions related to address processing
-
Zahoor Mohamed authored
* fixed redundent debug statements Co-authored-by:
acud <12988138+acud@users.noreply.github.com>
-
- 08 Jun, 2020 3 commits
-
-
Petar Radovic authored
* fix peer disconnect in peer registry
-
Janoš Guljaš authored
-
Janoš Guljaš authored
-
- 06 Jun, 2020 1 commit
-
-
acud authored
-
- 05 Jun, 2020 7 commits
-
-
Janoš Guljaš authored
-
Janoš Guljaš authored
Co-authored-by:
svetomir <svetomirsmiljkovic@gmail.com>
-
Zahoor Mohamed authored
-
Petar Radovic authored
* handshake with observable underlay
-
lash authored
-
Zahoor Mohamed authored
* Add db capacity flag
-
lash authored
-
- 04 Jun, 2020 1 commit
-
-
Zahoor Mohamed authored
* Tag for chunks
-
- 03 Jun, 2020 2 commits
-
-
lash authored
-
Petar Radovic authored
* fix bzz addr
-
- 02 Jun, 2020 1 commit
-
-
Petar Radovic authored
* Use bzz address accross bee * Hive with signature
-
- 29 May, 2020 5 commits
-
-
Janoš Guljaš authored
-
Ivan Vandot authored
-
Janoš Guljaš authored
-
Janoš Guljaš authored
-
acud authored
* debugapi/peer.go - the AddPeer method on kademlia was called after connecting to the peer. this is legacy from the full topology implementation and is incorrect in this case. The resulting behavior would be that the peer would be connected to, then would be added to the known peers list, instead of both known and connect lists. So the kademlia would try to iterate in manage but the peer would never show up in the known peers list, so would never show up in the iterator. * it could be, that under certain circumstances that this peer would be gossiped to the node from another node, eventually triggering adding the peer through AddPeer, resulting in it being in the knownPeers slice. It is difficult to say what would be the behavior in such case, since AddPeer does not guarantee trying to connect to such a node, so we cannot guarantee in such case that the peer will ever shown in the connectedPeers list * kademlia.go - moved the addition of a peer to the connect peers list after connect has finished. this is to prevent a data race when we try to connect to a peer, but it has already dialed in but was not yet added to the kademlia (the Connected callback was not yet called). In this case the peer should also be added to the connected peers list. This call is of no harm, since duplicates are not allowed as part of pslice guarantees (they are skipped and not added) * kademlia.go - add peer to known peers slice on dial in - the problem was that a peer has dialed in, but was never known to us, resulting in an inconsistency in the kademlia node.go - peer should not be disconnected from when AddPeer fails in the case of kademlia (since AddPeer doesn't guarantee a connection)
-
- 28 May, 2020 3 commits
-
-
Janoš Guljaš authored
-
acud authored
-
acud authored
-
- 27 May, 2020 2 commits
-
-
acud authored
-
Janoš Guljaš authored
-
- 26 May, 2020 1 commit
-
-
acud authored
* initial kademlia implementation * implement `ClosestPeer` so that retrievals and push sync will work on kademlia * hook up kademlia to be the default topology, instead of `full` * add peer broadcasting functionality upon connecting to a peer * add peer announcement on dial-in
-
- 25 May, 2020 7 commits
-
-
Ivan Vandot authored
-
Ivan Vandot authored
-
Ivan Vandot authored
-
Janoš Guljaš authored
-
Janoš Guljaš authored
-
Janoš Guljaš authored
-
Janoš Guljaš authored
-
- 24 May, 2020 1 commit
-
-
Petar Radovic authored
* networkIID - binary encoding * refactor handshake tests
-
- 22 May, 2020 1 commit
-
-
Petar Radovic authored
* signing in handshake & Signer interface
-