diff --git a/Builds/VisualStudio2012/RippleD.vcxproj b/Builds/VisualStudio2012/RippleD.vcxproj
index 074dd34c97..f25fafc5be 100644
--- a/Builds/VisualStudio2012/RippleD.vcxproj
+++ b/Builds/VisualStudio2012/RippleD.vcxproj
@@ -2088,12 +2088,16 @@
+
+
true
true
true
true
+
+
@@ -2101,8 +2105,23 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/Builds/VisualStudio2012/RippleD.vcxproj.filters b/Builds/VisualStudio2012/RippleD.vcxproj.filters
index d33a1332dd..4c2fbc282f 100644
--- a/Builds/VisualStudio2012/RippleD.vcxproj.filters
+++ b/Builds/VisualStudio2012/RippleD.vcxproj.filters
@@ -2407,6 +2407,63 @@
[1] Ripple\testoverlay
+
+ [1] Ripple\peerfinder
+
+
+ [1] Ripple\validators
+
+
+ [1] Ripple\resource
+
+
+ [1] Ripple\resource
+
+
+ [1] Ripple\types
+
+
+ [1] Ripple\types
+
+
+ [1] Ripple\testoverlay
+
+
+ [1] Ripple\algorithm
+
+
+ [1] Ripple\algorithm
+
+
+ [1] Ripple\http
+
+
+ [1] Ripple\http
+
+
+ [1] Ripple\json
+
+
+ [1] Ripple\json
+
+
+ [1] Ripple\rpc
+
+
+ [1] Ripple\rpc
+
+
+ [1] Ripple\sitefiles
+
+
+ [1] Ripple\sitefiles
+
+
+ [1] Ripple\sslutil
+
+
+ [1] Ripple\sslutil
+
diff --git a/src/ripple/algorithm/README.md b/src/ripple/algorithm/README.md
new file mode 100644
index 0000000000..f284353318
--- /dev/null
+++ b/src/ripple/algorithm/README.md
@@ -0,0 +1,3 @@
+# Algorithm
+
+Various utility classes
diff --git a/src/ripple/algorithm/TODO.md b/src/ripple/algorithm/TODO.md
new file mode 100644
index 0000000000..b05e3dce4d
--- /dev/null
+++ b/src/ripple/algorithm/TODO.md
@@ -0,0 +1,5 @@
+# Algorithm TODO
+
+- Rethink the CycledSet (and cousin AgedCache). Make each element part
+ of an intrusive linked list, add a DiscreteClock data member, and
+ perform aging on each insertion or sweep rather than once in a while.
diff --git a/src/ripple/http/README.md b/src/ripple/http/README.md
new file mode 100644
index 0000000000..bf51b45b62
--- /dev/null
+++ b/src/ripple/http/README.md
@@ -0,0 +1,6 @@
+# HTTP Server
+
+A generic HTTP server. This is used for doing asynchronous RPC
+currently, although it could be expanded to perform more activities
+such as reporting to the elastic load balancer or providing server
+statistics.
diff --git a/src/ripple/http/TODO.md b/src/ripple/http/TODO.md
new file mode 100644
index 0000000000..960cda5dd5
--- /dev/null
+++ b/src/ripple/http/TODO.md
@@ -0,0 +1 @@
+# HTTP Server TODO
diff --git a/src/ripple/json/README.md b/src/ripple/json/README.md
new file mode 100644
index 0000000000..aed95107d3
--- /dev/null
+++ b/src/ripple/json/README.md
@@ -0,0 +1,3 @@
+# JSON
+
+Third party library to do JSON operations.
diff --git a/src/ripple/json/TODO.md b/src/ripple/json/TODO.md
new file mode 100644
index 0000000000..c77c36363d
--- /dev/null
+++ b/src/ripple/json/TODO.md
@@ -0,0 +1,7 @@
+# JSON TODO
+
+- Investigate other third party libraries, especially those that are
+ proven hardened against attacks, or perform better
+
+- Implement canonical JSON API to do signing
+
diff --git a/src/ripple/peerfinder/README.md b/src/ripple/peerfinder/README.md
index f6603a837a..628ae31ce1 100644
--- a/src/ripple/peerfinder/README.md
+++ b/src/ripple/peerfinder/README.md
@@ -30,3 +30,194 @@ The PeerFinder module has these responsibilities:
+
+### Exposition
+
+(Formerly in Manager.cpp, needs to be reformatted and tidied)
+
+PeerFinder
+----------
+
+ Implements the logic for announcing and discovering IP addresses for
+ for connecting into the Ripple network.
+
+Introduction
+------------
+
+Each Peer (a computer running rippled) on the Ripple network requires a certain
+number of connections to other peers. These connections form an "overlay
+network." When a new peer wants to join the network, they need a robust source
+of network addresses (IP addresses) in order to establish outgoing connections.
+Once they have joined the network, they need a method of announcing their
+availaibility of accepting incoming connections.
+
+The Ripple network, like all peer to peer networks, defines a "directed graph"
+where each node represents a computer running the rippled software, and each
+vertex indicates a network connection. The direction of the connection tells
+us whether it is an outbound or inbound connection (from the perspective of
+a particular node).
+
+Fact #1:
+ The total inbound and outbound connections of any overlay must be equal.
+
+This follows that for each node that has an established outbound connection,
+there must exist another node that has received the corresponding inbound
+connection.
+
+When a new peer joins the network it may or may not wish to receive inbound
+connections. Some peers are unable to accept incoming connections for various.
+For security reasons they may be behind a firewall that blocks accept requests.
+The administers may decide they don't want the connection traffic. Or they
+may wish to connect only to specific peers. Or they may simply be misconfigured.
+
+If a peer decides that it wishes to receive incoming connections, it needs
+a method to announce its IP address and port number, the features that it
+offers (for example, that it also services client requests), and the number
+of available connection slots. This is to handle the case where the peer
+reaches its desired number of peer connections, but may still want to inform
+the network that it will service clients. It may also be desired to indicate
+the number of free client slots.
+
+Once a peer is connected to the network we need a way both to inform our
+neighbors of our status with respect to accepting connections, and also to
+learn about new fresh addresses to connect to. For this we will define the
+mtENDPOINTS message.
+
+"Bootstrap Strategy"
+--------------------
+
+Nouns:
+
+ bootstrap_ip
+ numeric IPAddress
+
+ bootstrap_domain
+ domain name / port combinations, resolution only
+
+ bootstrap_url
+ URL leading to a text file, with a series of entries.
+
+ ripple.txt
+ Separately parsed entity outside of PeerFinder that can provide
+ bootstrap_ip, bootstrap_domain, and bootstrap_url items.
+
+The process of obtaining the initial peer connections for accessing the Ripple
+peer to peer network, when there are no current connections, is called
+"bootstrapping." The algorithm is as follows:
+
+1. If ( unusedLiveEndpoints.count() > 0
+ OR activeConnectionAttempts.count() > 0)
+ Try addresses from unusedLiveEndpoints
+ return;
+2. If ( domainNames.count() > 0 AND (
+ unusedBootstrapIPs.count() == 0
+ OR activeNameResolutions.count() > 0) )
+ ForOneOrMore (DomainName that hasn't been resolved recently)
+ Contact DomainName and add entries to the unusedBootstrapIPs
+ return;
+3. If (unusedBootstrapIPs.count() > 0)
+ Try addresses from unusedBootstrapIPs
+ return;
+4. Try entries from [ips]
+5. Try entries from [ips_urls]
+6. Increment generation number and go to 1
+
+ - Keep a map of all current outgoing connection attempts
+
+"Connection Strategy"
+---------------------
+
+This is the overall strategy a peer uses to maintain its position in the Ripple
+network graph
+
+We define these values:
+
+ peerCount (calculated)
+ The number of currently connected and established peers
+
+ outCount (calculated)
+ The number of peers in PeerCount that are outbound connections.
+
+ MinOutCount (hard-coded constant)
+ The minimum number of OutCount we want. This also puts a floor
+ on PeerCount. This protects against sybil attacks and makes
+ sure that ledgers can get retrieved reliably.
+ 10 is the proposed value.
+
+ MaxPeerCount (a constant set in the rippled.cfg)
+ The maximum number of peer connections, inbound or outbound,
+ that a peer wishes to maintain. Setting MaxPeerCount equal to
+ or below MinOutCount would disallow incoming connections.
+
+ OutPercent (a baked-in program constant for now)
+ The peer's target value for OutCount. When the value of OutCount
+ is below this number, the peer will employ the Outgoing Strategy
+ to raise its value of OutCount. This value is initially a constant
+ in the program, defined by the developers. However, it
+ may be changed through the consensus process.
+ 15% is a proposed value.
+
+However, lets consider the case where OutDesired is exactly equal to MaxPeerCount / 2.
+In this case, a stable state will be reached when every peer is full, and
+has exactly the same number of inbound and outbound connections. The problem
+here is that there are now no available incoming connection slots. No new
+peers can enter the network.
+
+Lets consider the case where OutDesired is exactly equal to (MaxPeerCount / 2) - 1.
+The stable state for this network (assuming all peers can accept incoming) will
+leave us with network degree equal to MaxPeerCount - 2, with all peers having two
+available incoming connection slots. The global number of incoming connection slots
+will be equal to twice the number of nodes on the network. While this might seem to
+be a desirable outcome, note that the connectedness (degree of the overlay) plays
+a large part in determining the levels of traffic and ability to receive validations
+from desired nodes. Having every node with available incoming connections also
+means that entries in pong caches will continually fall out with new values and
+information will become less useful.
+
+For this reason, we advise that the value of OutDesired be fractional. Upon startup,
+a node will use its node ID (its 160 bit unique ID) to decide whether to round the
+value of OutDesired up or down. Using this method, we can precisely control the
+global number of available incoming connection slots.
+
+"Outgoing Strategy"
+-------------------
+
+This is the method a peer uses to establish outgoing connections into the
+Ripple network.
+
+A peer whose PeerCount is zero will use these steps:
+ 1. Attempt addresses from a local database of addresses
+ 2. Attempt addresses from a set of "well known" domains in rippled.cfg
+
+
+This is the method used by a peer that is already connected to the Ripple network,
+to adjust the number of outgoing connections it is maintaining.
+
+
+"Incoming Strategy"
+------------------------------
+
+This is the method used by a peer to announce its ability and desire to receive
+incoming connections both for the purpose of obtaining additional peer connections
+and also for receiving requests from clients.
+
+Overlay Network
+ http://en.wikipedia.org/wiki/Overlay_network
+
+Directed Graph
+ http://en.wikipedia.org/wiki/Directed_graph
+
+References:
+
+Gnutella 0.6 Protocol
+ 2.2.2 Ping (0x00)
+ 2.2.3 Pong (0x01)
+ 2.2.4 Use of Ping and Pong messages
+ 2.2.4.1 A simple pong caching scheme
+ 2.2.4.2 Other pong caching schemes
+ http://rfc-gnutella.sourceforge.net/src/rfc-0_6-draft.html
+
+Revised Gnutella Ping Pong Scheme
+ By Christopher Rohrs and Vincent Falco
+ http://rfc-gnutella.sourceforge.net/src/pong-caching.html
+
diff --git a/src/ripple/peerfinder/TODO.md b/src/ripple/peerfinder/TODO.md
new file mode 100644
index 0000000000..5739473130
--- /dev/null
+++ b/src/ripple/peerfinder/TODO.md
@@ -0,0 +1,4 @@
+# PeerFinder TODO
+
+- Add TestOverlay unit test that passes mtENDPOINTs messages
+ around and enforces connection policy using a custom Callback.
diff --git a/src/ripple/peerfinder/impl/Manager.cpp b/src/ripple/peerfinder/impl/Manager.cpp
index 31323c5b22..de88e784a1 100644
--- a/src/ripple/peerfinder/impl/Manager.cpp
+++ b/src/ripple/peerfinder/impl/Manager.cpp
@@ -17,200 +17,6 @@
*/
//==============================================================================
-/*
-
-PeerFinder
-----------
-
- Implements the logic for announcing and discovering IP addresses for
- for connecting into the Ripple network.
-
-Introduction
-------------
-
-Each Peer (a computer running rippled) on the Ripple network requires a certain
-number of connections to other peers. These connections form an "overlay
-network." When a new peer wants to join the network, they need a robust source
-of network addresses (IP addresses) in order to establish outgoing connections.
-Once they have joined the network, they need a method of announcing their
-availaibility of accepting incoming connections.
-
-The Ripple network, like all peer to peer networks, defines a "directed graph"
-where each node represents a computer running the rippled software, and each
-vertex indicates a network connection. The direction of the connection tells
-us whether it is an outbound or inbound connection (from the perspective of
-a particular node).
-
-Fact #1:
- The total inbound and outbound connections of any overlay must be equal.
-
-This follows that for each node that has an established outbound connection,
-there must exist another node that has received the corresponding inbound
-connection.
-
-When a new peer joins the network it may or may not wish to receive inbound
-connections. Some peers are unable to accept incoming connections for various.
-For security reasons they may be behind a firewall that blocks accept requests.
-The administers may decide they don't want the connection traffic. Or they
-may wish to connect only to specific peers. Or they may simply be misconfigured.
-
-If a peer decides that it wishes to receive incoming connections, it needs
-a method to announce its IP address and port number, the features that it
-offers (for example, that it also services client requests), and the number
-of available connection slots. This is to handle the case where the peer
-reaches its desired number of peer connections, but may still want to inform
-the network that it will service clients. It may also be desired to indicate
-the number of free client slots.
-
-Once a peer is connected to the network we need a way both to inform our
-neighbors of our status with respect to accepting connections, and also to
-learn about new fresh addresses to connect to. For this we will define the
-mtENDPOINTS message.
-
-"Bootstrap Strategy"
---------------------
-
-Nouns:
-
- bootstrap_ip
- numeric IPAddress
-
- bootstrap_domain
- domain name / port combinations, resolution only
-
- bootstrap_url
- URL leading to a text file, with a series of entries.
-
- ripple.txt
- Separately parsed entity outside of PeerFinder that can provide
- bootstrap_ip, bootstrap_domain, and bootstrap_url items.
-
-The process of obtaining the initial peer connections for accessing the Ripple
-peer to peer network, when there are no current connections, is called
-"bootstrapping." The algorithm is as follows:
-
-1. If ( unusedLiveEndpoints.count() > 0
- OR activeConnectionAttempts.count() > 0)
- Try addresses from unusedLiveEndpoints
- return;
-2. If ( domainNames.count() > 0 AND (
- unusedBootstrapIPs.count() == 0
- OR activeNameResolutions.count() > 0) )
- ForOneOrMore (DomainName that hasn't been resolved recently)
- Contact DomainName and add entries to the unusedBootstrapIPs
- return;
-3. If (unusedBootstrapIPs.count() > 0)
- Try addresses from unusedBootstrapIPs
- return;
-4. Try entries from [ips]
-5. Try entries from [ips_urls]
-6. Increment generation number and go to 1
-
- - Keep a map of all current outgoing connection attempts
-
-
-"Connection Strategy"
----------------------
-
-This is the overall strategy a peer uses to maintain its position in the Ripple
-network graph
-
-We define these values:
-
- peerCount (calculated)
- The number of currently connected and established peers
-
- outCount (calculated)
- The number of peers in PeerCount that are outbound connections.
-
- MinOutCount (hard-coded constant)
- The minimum number of OutCount we want. This also puts a floor
- on PeerCount. This protects against sybil attacks and makes
- sure that ledgers can get retrieved reliably.
- 10 is the proposed value.
-
- MaxPeerCount (a constant set in the rippled.cfg)
- The maximum number of peer connections, inbound or outbound,
- that a peer wishes to maintain. Setting MaxPeerCount equal to
- or below MinOutCount would disallow incoming connections.
-
- OutPercent (a baked-in program constant for now)
- The peer's target value for OutCount. When the value of OutCount
- is below this number, the peer will employ the Outgoing Strategy
- to raise its value of OutCount. This value is initially a constant
- in the program, defined by the developers. However, it
- may be changed through the consensus process.
- 15% is a proposed value.
-
-However, lets consider the case where OutDesired is exactly equal to MaxPeerCount / 2.
-In this case, a stable state will be reached when every peer is full, and
-has exactly the same number of inbound and outbound connections. The problem
-here is that there are now no available incoming connection slots. No new
-peers can enter the network.
-
-Lets consider the case where OutDesired is exactly equal to (MaxPeerCount / 2) - 1.
-The stable state for this network (assuming all peers can accept incoming) will
-leave us with network degree equal to MaxPeerCount - 2, with all peers having two
-available incoming connection slots. The global number of incoming connection slots
-will be equal to twice the number of nodes on the network. While this might seem to
-be a desirable outcome, note that the connectedness (degree of the overlay) plays
-a large part in determining the levels of traffic and ability to receive validations
-from desired nodes. Having every node with available incoming connections also
-means that entries in pong caches will continually fall out with new values and
-information will become less useful.
-
-For this reason, we advise that the value of OutDesired be fractional. Upon startup,
-a node will use its node ID (its 160 bit unique ID) to decide whether to round the
-value of OutDesired up or down. Using this method, we can precisely control the
-global number of available incoming connection slots.
-
-"Outgoing Strategy"
--------------------
-
-This is the method a peer uses to establish outgoing connections into the
-Ripple network.
-
-A peer whose PeerCount is zero will use these steps:
- 1. Attempt addresses from a local database of addresses
- 2. Attempt addresses from a set of "well known" domains in rippled.cfg
-
-
-This is the method used by a peer that is already connected to the Ripple network,
-to adjust the number of outgoing connections it is maintaining.
-
-
-"Incoming Strategy"
-------------------------------
-
-This is the method used by a peer to announce its ability and desire to receive
-incoming connections both for the purpose of obtaining additional peer connections
-and also for receiving requests from clients.
-
-
-
-Terms
-
-Overlay Network
- http://en.wikipedia.org/wiki/Overlay_network
-
-Directed Graph
- http://en.wikipedia.org/wiki/Directed_graph
-
-References:
-
-Gnutella 0.6 Protocol
- 2.2.2 Ping (0x00)
- 2.2.3 Pong (0x01)
- 2.2.4 Use of Ping and Pong messages
- 2.2.4.1 A simple pong caching scheme
- 2.2.4.2 Other pong caching schemes
- http://rfc-gnutella.sourceforge.net/src/rfc-0_6-draft.html
-
-Revised Gnutella Ping Pong Scheme
- By Christopher Rohrs and Vincent Falco
- http://rfc-gnutella.sourceforge.net/src/pong-caching.html
-*/
-
namespace ripple {
namespace PeerFinder {
diff --git a/src/ripple/resource/TODO.md b/src/ripple/resource/TODO.md
new file mode 100644
index 0000000000..e0c2c154ee
--- /dev/null
+++ b/src/ripple/resource/TODO.md
@@ -0,0 +1 @@
+# ResourceManager TODO
diff --git a/src/ripple/rpc/README.md b/src/ripple/rpc/README.md
new file mode 100644
index 0000000000..cb52d938dd
--- /dev/null
+++ b/src/ripple/rpc/README.md
@@ -0,0 +1,3 @@
+# RPC
+
+New code to generalize the operation of RPC commands
diff --git a/src/ripple/rpc/TODO.md b/src/ripple/rpc/TODO.md
new file mode 100644
index 0000000000..e22c3712d6
--- /dev/null
+++ b/src/ripple/rpc/TODO.md
@@ -0,0 +1,6 @@
+# RPC TODO
+
+- Redo the interface to actually work correctly for the existing
+ use-cases that the old code supports. Specifically that RPC commands
+ can be issued for a particular context like a websocket connection
+ or other subscriber.
diff --git a/src/ripple/sitefiles/README.md b/src/ripple/sitefiles/README.md
new file mode 100644
index 0000000000..0f9cbe58f3
--- /dev/null
+++ b/src/ripple/sitefiles/README.md
@@ -0,0 +1,4 @@
+# SiteFiles
+
+A central module that manages the download of local and remote ripple.txt files
+and allows other code modules to access the sections.
diff --git a/src/ripple/sitefiles/TODO.md b/src/ripple/sitefiles/TODO.md
new file mode 100644
index 0000000000..64904f9475
--- /dev/null
+++ b/src/ripple/sitefiles/TODO.md
@@ -0,0 +1,9 @@
+# SiteFiles TODO
+
+- UnitTest
+
+- Use it in more places
+
+- Process the local file
+
+
diff --git a/src/ripple/sslutil/README.md b/src/ripple/sslutil/README.md
new file mode 100644
index 0000000000..5e3e4a1dc3
--- /dev/null
+++ b/src/ripple/sslutil/README.md
@@ -0,0 +1,4 @@
+# SSLUtil
+
+This module exposes the OpenSSL headers and provides utilities to
+operate with OpenSSL / BIGNUM objects.
diff --git a/src/ripple/sslutil/TODO.md b/src/ripple/sslutil/TODO.md
new file mode 100644
index 0000000000..fc6a847bdf
--- /dev/null
+++ b/src/ripple/sslutil/TODO.md
@@ -0,0 +1 @@
+# SSLUtil TODO
diff --git a/src/ripple/testoverlay/TODO.md b/src/ripple/testoverlay/TODO.md
new file mode 100644
index 0000000000..91521ba401
--- /dev/null
+++ b/src/ripple/testoverlay/TODO.md
@@ -0,0 +1,6 @@
+# TestOverlay TODO
+
+- Add documentation
+
+- Fix the templates to be sane, use derivation and virtual instead of
+ compile time polymorphism
diff --git a/src/ripple/types/README.md b/src/ripple/types/README.md
new file mode 100644
index 0000000000..5cddea0624
--- /dev/null
+++ b/src/ripple/types/README.md
@@ -0,0 +1,3 @@
+# Types
+
+Provides various types that are specific to the Ripple payment network.
diff --git a/src/ripple/types/TODO.md b/src/ripple/types/TODO.md
new file mode 100644
index 0000000000..cd2811731a
--- /dev/null
+++ b/src/ripple/types/TODO.md
@@ -0,0 +1,7 @@
+# Types TODO
+
+- Replace uint128, uint160, uint256 with solid types
+
+- Clean up and optimize Base58 conversions
+
+- Generalize AgedHistory to use a DiscreteClock and not have two maps
diff --git a/src/ripple/validators/TODO.md b/src/ripple/validators/TODO.md
new file mode 100644
index 0000000000..c7f28ca76b
--- /dev/null
+++ b/src/ripple/validators/TODO.md
@@ -0,0 +1 @@
+# Validators TODO
diff --git a/src/ripple/validators/impl/Manager.cpp b/src/ripple/validators/impl/Manager.cpp
index f1e621eb4c..f1807e293c 100644
--- a/src/ripple/validators/impl/Manager.cpp
+++ b/src/ripple/validators/impl/Manager.cpp
@@ -169,6 +169,7 @@ public:
//
// Manager
//
+ //--------------------------------------------------------------------------
void addStrings (String name, std::vector const& strings)
{
@@ -245,6 +246,7 @@ public:
//
// Stoppable
//
+ //--------------------------------------------------------------------------
void onPrepare ()
{
@@ -290,6 +292,7 @@ public:
//
// PropertyStream
//
+ //--------------------------------------------------------------------------
void onWrite (PropertyStream::Map& map)
{
@@ -319,6 +322,7 @@ public:
//
// ManagerImp
//
+ //--------------------------------------------------------------------------
void init ()
{