Spec update

ethcloud.md

@@ -43,6 +43,11 @@ MAC tables. All frames without a tag will be treated as having tag `0`.
 The peer-to-peer protocol will cause nodes to exchange information about their
 peers. For nodes behind a firewall or a NAT, this can function as hole-punching.
 
+Ethcloud should be able to scale to a few thousand nodes with reasonable
+management traffic (below 10 KiB/s for 10.000 nodes). However, such huge
+networks will cause a lot of traffic due to broadcasts. At this point, a routed
+approach should be preferred.
+
 
 ## NETWORK PROTOCOL
 
@@ -83,11 +88,11 @@ of the packet:
 Nodes are expected to request the peer list from the initial nodes they are
 connecting to. After that, they should periodically send their peer list to all
 of their peers to spread this information and to avoid peer timeouts.
-To avoid the cubic growth of management traffic, nodes should select a subset of
+To avoid the cubic growth of management traffic, nodes should at a certain
-peers and send them a subset of their peer information. A reasonable number
+network size start sending partial peer lists instead of the full list.
-would be the square root of the number of peers. The subsets can be selected
+A reasonable number would be the square root of the number of peers.
-using round robin (making sure all peers eventually receive all information)
+The subsets can be selected using round robin (making sure all peers eventually
-or randomly.
+receive all information) or randomly.
 
 Nodes should remove peers from their peer list after a certain period of
 inactivity or when receiving a `Close` message. Before shutting down, nodes

src/main.rs

@@ -16,8 +16,6 @@ use docopt::Docopt;
 use ethcloud::{Error, Token, EthCloud};
 
 
-//FIXME: Send peer list in several packets when too large. The current behaviour panics at about
-//       10000 peers.
 //TODO: Implement IPv6
 //TODO: Encryption
 //TODO: Call close