Merge tag 'neo-v0.11.0' into v14.x.x

neo-v0.11.0

Build.mak

@@ -1,5 +1,6 @@
 export ASSERT_ON_STOMPING_PREVENTION=1
 
+override LDFLAGS += -llzo2 -lebtree -lrt -lgcrypt -lgpg-error -lglib-2.0 -lpcre
 override DFLAGS  += -w
 
 ifeq ($(DVER),1)
@@ -14,9 +15,6 @@ $B/fakedht: override LDFLAGS += -llzo2 -lebtree -lrt -lpcre
 
 all += $B/fakedht
 
-$O/%unittests: override LDFLAGS += -llzo2 -lebtree -lrt -lpcre
-
-$O/test-fakedht: override LDFLAGS += -llzo2 -lebtree  -lrt -lpcre
 $O/test-fakedht: $B/fakedht
 
 $B/dhtapp: $C/src/dummydhtapp/main.d

README.rst

@@ -14,6 +14,27 @@ Table (DHT), including:
   The test is run, in this repo, on a fake node, but it can be reused in other
   repos to test real node implementations. (``src.dhttest``)
 
+A Tale of Two Protocols
+-----------------------
+
+The code in this repo is currently in transition. There exist two parallel
+client/server architectures in the repo, a new architecture (dubbed "neo") --
+based on the core code in the ``swarm/neo`` package -- and a legacy architecture
+-- based on the core code located in the other packages of ``swarm``. The neo
+protocol is being introduced in stages, progressively adding features to the
+core client and server code over a series of alpha releases in a separate branch
+(named ``neo``).
+
+Note that the DHT client and node defined in this repo support *both* neo and
+legacy features.
+
+When the alpha releases are considered stable, the ``neo`` branch will be merged
+into the main release branch (currently ``v13.x.x``).
+
+When sufficient neo features have been implemented and the legacy protocol is no
+longer in active use, the legacy protocol will be deprecated and eventually
+removed.
+
 Dependencies
 ============
 

beaver.Dockerfile

@@ -1 +1 @@
-FROM sociomantictsunami/dlang:v2
+FROM sociomantictsunami/dlang:v3

docker/build

@@ -2,7 +2,6 @@
 set -xe
 
 # Install dependencies
-apt-get update
 apt-get install -y \
     liblzo2-dev \
     libebtree6-dev \

relnotes/connect.feature.md

@@ -0,0 +1,12 @@
+### Simple methods to connect to a node or cluster
+
+`dhtproto.client.mixins.NeoSupport`
+
+The blocking API now has three additional methods named `connect`. These add
+either a single node (specified either by address & port or purely by port) or
+a cluster of nodes (specified by a config file) to the registry, and then blocks
+the current `Task` until the hash range of all nodes has been fetched.
+
+These new methods are intended to simplify use of the DHT client in test code
+and scripts.
+

relnotes/ctor.feature.md

@@ -0,0 +1,15 @@
+### New, ultra-minimal client ctor for use in scripts/tests
+
+`dhtproto.client.DhtClient`
+
+The existing constructors require an epoll instance and various user-specified
+configuration settings. The newly added constructor allows a DHT client to be
+instantiated with no configuration whatsoever:
+
+```
+auto dht = new DhtClient; // uses Task-scheduler's epoll instance
+```
+
+This greatly reduces the amount of boilerplate required to use a DHT client in
+a script or test.
+

relnotes/neo.feature.md

@@ -0,0 +1,8 @@
+### Neo protocol is now mainstream
+
+`dhtproto.client.DhtClient`
+
+The DHT client now has the facility to use the neo protocol. For full
+documentation on the DHT neo protocol and requests, see
+`dhtproto.client.README.md`.
+