maidsafe-archive / crust Goto Github PK

Calling send with a message containing spaces only sends the part before the first space, regardless of wrapping the message in single or double quotes. No error message is shown to indicate the failure (although what has actually been sent is shown, so the user could spot the error there).

The initial node of a new network connects to itself - it looks like the beacon GUID is not being sent.

Subj.

The bootstrap file is located in the current working dir (at the time when the app is started).

This makes it pointless to install a default bootstrap file, since it will be ignored unless the user happens to cd to the location of the installed file before starting the app.

The example should automatically use the beacon facilities. The command line help message implies this will happen, but running the exe with no args only causes the help message to be displayed again.

Can the example name crust_node be updated - to make it clear what the example does.
Also should simple_receiver and simple_sender be included in the examples bundle?

Crust's bootstrap method should try to connect to multiple endpoints discovered from multiple sources (responses from multiple beacon listeners and also local bootstrap.cache file).
This means the crust bootstrap method should return vector of n endpoints it is connected to.

Details :

If there are X Beacon servers in a LAN and each one of them return Y bootstrap endpoints,
CRUST needs to return after validating each endpoint can be successfully connected a maximum of either X * Y connected endpoints(provided all Y endpoints returned by each beacon server are valid) or introduce a filter to limit connections per beacon server / total returned to the consumer of this library.
(same applies for endpoints from local bootstrap.cache file and any further sources we support in crust library)

Needs to be decided: (should 'n' be definable? and if so by which of the following approaches) Allow consumer of this lib to either specify filter based on cap connections per beacon server / total capped connections returned by CRUST / no filter

When trying to bootstrap to an existing "server" crust node by doing

target\debug\examples\crust_node.exe 5555 -b 5483

I get the following output:

Failed to bootstrap from provided peers with error : No bootstrap node got connected
thread '<main>' panicked at 'Not resorting to default discovery of bootstrap nodes. Exiting', examples/crust_node.rs:265
stop listening

Having one config file in a hardcoded location may be fine for your use-case but if this library is supposed to be usefull for other server-less / decentralised projects then there should be a way to specify all neceasarry information using API. One obvious use-case that doesn't work well with one config file per process is connecting to multiple decentralized network (currently the only way I see to do it is to change currrent directory before creating ConnectionManager, correct me if I'm wrong).

Testing environment : Ubuntu 15.04 / rustc 1.2.0-nightly (2015-06-09) - 20 x crust_peer nodes started.

The first node on the networks has 38 connected nodes>

Enter command (stop | connect <endpoint> | send <endpoint> <message>)>
Connected to peer at Tcp(V4(192.168.1.93:38237))
38 connected nodes: Tcp(V4(127.0.0.1:41734)) Tcp(V4(192.168.1.93:38087))
Tcp(V4(127.0.0.1:41743)) Tcp(V4(192.168.1.93:38096)) Tcp(V4(127.0.0.1:41751))
Tcp(V4(192.168.1.93:38104)) Tcp(V4(127.0.0.1:41759)) Tcp(V4(192.168.1.93:38112))
Tcp(V4(127.0.0.1:41767)) Tcp(V4(192.168.1.93:38120)) Tcp(V4(127.0.0.1:41776))
Tcp(V4(192.168.1.93:38129)) Tcp(V4(127.0.0.1:41784)) Tcp(V4(192.168.1.93:38137))
Tcp(V4(127.0.0.1:41792)) Tcp(V4(192.168.1.93:38145)) Tcp(V4(127.0.0.1:41800))
Tcp(V4(192.168.1.93:38153)) Tcp(V4(127.0.0.1:41808)) Tcp(V4(192.168.1.93:38161))
Tcp(V4(127.0.0.1:41820)) Tcp(V4(192.168.1.93:38173)) Tcp(V4(127.0.0.1:41828))
Tcp(V4(192.168.1.93:38181)) Tcp(V4(127.0.0.1:41834)) Tcp(V4(192.168.1.93:38187))
Tcp(V4(127.0.0.1:41842)) Tcp(V4(192.168.1.93:38195)) Tcp(V4(127.0.0.1:41852))
Tcp(V4(192.168.1.93:38205)) Tcp(V4(127.0.0.1:41860)) Tcp(V4(192.168.1.93:38213))
Tcp(V4(127.0.0.1:41868)) Tcp(V4(192.168.1.93:38221)) Tcp(V4(127.0.0.1:41876))
Tcp(V4(192.168.1.93:38229)) Tcp(V4(127.0.0.1:41884)) Tcp(V4(192.168.1.93:38237))

The other 19 all have 2 >

Enter command (stop | connect <endpoint> | send <endpoint> <message>)>
Connected to peer at Tcp(V4(127.0.0.1:40740))
2 connected nodes: Tcp(V4(192.168.1.93:40740)) Tcp(V4(127.0.0.1:40740))

I don't think the listening port should be a requirement - we can allow this to be randomly assigned normally.

We have decided to allow two nodes trying to connect to eachother on TCP to establish two connections.

The comments in crust_node.rs state e.g.

// starting second node : cargo run --example crust_node -- 5883 -b 0.0.0.0:5983

The output from running a crust_node in server mode by doing

target\debug\examples\crust_node.exe -o 6666

yields the following output:

Connection manager now listening on TCP socket 0.0.0.0:6666

However, when connecting another node, we need to use the server's actual IP address, not 0.0.0.0.

The bootstrap file's contents are all contained on one line.

It would be good to do some sort of "pretty print" to make it easier to read and modify this file.

I ran a Client example with a bootstrap file containing the following at the start:

{
  "preferred_port": {
    "variant": "Tcp",
    "fields": [
      5483
    ]
  },
  "hard_coded_contacts": [
    {
      "endpoint": "45.55.207.180:5483"
    },
    {
      "endpoint": "178.62.7.96:5483"
    },
    {
      "endpoint": "128.199.199.210:5483"
    },
    {
      "endpoint": "37.59.98.1:5483"
    },
    {
      "endpoint": "45.79.93.11:5483"
    },
    {
      "endpoint": "45.79.2.52:5483"
    },
  ],
  "contacts": [
    {
      "endpoint": "45.55.207.180:5483"
    },
    {
      "endpoint": "178.62.7.96:5483"
    },
    {
      "endpoint": "128.199.199.210:5483"
    },
    {
      "endpoint": "37.59.98.1:5483"
    },
    {
      "endpoint": "45.79.93.11:5483"
    },
    {
      "endpoint": "45.79.2.52:5483"
    },
  ]
}

After the example ran, it contained:

{
  "preferred_port": {
    "variant": "Tcp",
    "fields": [
      0
    ]
  },
  "hard_coded_contacts": [],
  "contacts": [
    {
      "endpoint": "127.0.0.1:48660"
    },
    {
      "endpoint": "192.168.1.65:48660"
    },
    {
      "endpoint": "[::1]:48660"
    }
  ]
}

CRUSTv0.2.0

when populating the accepting_on endpoints in routing, I find that I get eg

local_endpoints: [Tcp(V4(127.0.0.1:0)), Tcp(V4(192.168.0.32:0)), Tcp(V4(172.17.42.1:0))]

so on the receiving end of the connect_request message, the connect_manager.connect() call is not effective, and routing can't establish a new connection between the two nodes.

panic! should be replaced with println! and std::os::set_exit_status

Running an example from the MaidSafe Client project shows that a client can't connect to a vault network which is running on remote Droplets.

The example doesn't allow for passing through endpoints via the command line (as other examples do) which means that I added six endpoints to the bootstrap file before launching the example.

I tried adding the list of endpoints to the hardcoded section and the contacts section of the file.

The client apparently doesn't connect to any of the running vaults.

rustc 1.2.0-nightly (2f5683913 2015-06-18)

The stop command in the crust_peer example in Linux seems to no longer work.

Rust 1.1 now targets musl, this will means 100% statically linked binaries with zero dependencies

It looks like we unconditionally add peer TCP endpoints to the bootstrap list, even though the remote end may not be a TCP listening endpoint and will be unable to accept new connections.

There is no 'tool' for generating a random endpoint for tests. Possiblty worth considering.

bootstrap Tcp(V4(172.17.42.1:32823))
is this not a special address range?

On Windows, started first "server" node by doing:

target\debug\examples\crust_node.exe -o 7777

This completes apparently successfully. Then started second node on same machine by doing:

target\debug\examples\crust_node.exe 5555 -b 192.168.0.34:7777

Server node outputs:

connected nodes : 192.168.0.34:50266
connected nodes : 192.168.0.34:50266,192.168.0.34:50267
dropping node:192.168.0.34:50266
dropping node:192.168.0.34:50267

which appears as though there are briefly two connections between the server and the second node, but both are immediately dropped. The output from the second node is:

Connection manager now listening on TCP socket 0.0.0.0:5555
bootstrapped to 192.168.0.34:7777
connected nodes : 192.168.0.34:7777
connecting to 192.168.0.34:7777
input command ( stop | connect <Endpoint> | send <Endpoint> <Msg> )  >>>
connected nodes : 192.168.0.34:7777
dropping node:192.168.0.34:7777

The fault can be found by running two instances of the crust_node example. The second node should be connected to the first's listening endpoint. If you then try and connect again from the second node to the first's listener, the connection is briefly established, but then both the original connection and the new one are dropped.

I believe this is down to a misunderstanding of how HashMap::insert works. I had wrongly assumed (despite reading the docs) that it would behave similarly to the C++ equivalent, but it doesn't. It returns the value which was previously there and replaces it with the new value.

We keep a HashMap of channels, indexed by endpoint. So when the second attempt to insert the same endpoint happens, we get the original channel returned and replace it with the new one. We ignore the return value of the insert using let _ =, so the original channel is almost immediately destroyed.

This causes that channel's reader thread to break out of its loop, reporting "receiving on a closed channel". When the loop exits, we unregister that endpoint - i.e. we remove that entry from the HashMap. However, the HashMap now contains the new channel at that endpoint, so when we remove the entry, we destroy the new channel too, causing both TCP connections to be dropped.

Contact struct should not hold Timestamp information.
it should be :

pub struct Contact {
    pub endpoint: Endpoint,
}

Also all Timestamp related methods/helpers should be internal to Bootstrap handler.

Ensure contents of Bootstrap file are unique

Useful link
http://bluss.github.io/rust-itertools/doc/itertools/trait.Itertools.html#method.unique

Can I suggest that crust's wire protocol always begins with this magic:

0x31757263 ("cru1")

This allows future wire protocol upgrade ("cru2") plus lets wireshark spot the protocol.

On Ubuntu, I can still see loop back address getting reported by running crust example and not the local address.
This is seen even after the fix for it already in the code (#104)

$ cargo run --example crust_node
   Compiling crust v0.0.8 (file:///home/prakash/rust/maidsafe/crust)
     Running `target/debug/examples/crust_node`
Listening for new connections on Tcp(V4(127.0.1.1:34005)), and listening for UDP broadcast on port 9999.
Didn't bootstrap to an existing network - this is the first node of a new network.

Enter command (stop | connect <endpoint> | send <endpoint> <message>)>

When trying to bootstrap to an existing "server" crust node by doing

target\debug\examples\crust_node.exe 5555 -b 5483

I get the following output:

Failed to parse bootstrap peer as valid IPv4 or IPv6 address: 5483

This implies that the server is returning a port as an endpoint.

When running a testnet of nodes running crust_node example, it becomes increasing slow to connect a new node to the network.

My suspicion is that the bootstrap list being returned by the beacon node is growing ever larger (and can contain permanently dead nodes from previous runs) and we're attempting to connect to these listed nodes sequentially.

When trying to bootstrap to an existing "server" crust node by doing

target\debug\examples\crust_node.exe 5555 -b 5483

I get the following output:

Received IPv4 address 0.0.0.0:5493

Received IPv4 address 0.0.0.0:5555

Received IPv4 address 0.0.0.0:5555

Received IPv4 address 0.0.0.0:5555

This repeated address represents previous failed attempts to bootstrap off the server.

When I am looking at the failed vault::executable_test issue in OSX, a strange behaviour is noticed:
for some reason, a node's msg connection will be trapped in receiving un-recognized msg infinitely.
i.e. It is observed that for a potential peer connection, Ok(crust::Event::NewMessage(endpoint, bytes)) => in routing will be constantly called and the incoming msg from the same endpoint turns out to be unrecognizable.
and once one side falls into this state, it can't recover from it, and can not put peer node into its routing table. (even the peer has already succeeded in doing so)

Although it is on routing level this behaviour is observed, because it is crust making such event call, so I am raising this issue in crust lib first.
If it turns out to be some bug in routing, please move the issue to routing, thanks.

I would like to create a crust_irc client based off of the crust_peer example, but I don't know enough rust to create it. I gave it my best shot, but diving right into a project like this with 0 rust experience is just over my head! So, I decided to try the next best thing: creating the design specifications!

https://github.com/a-jamesregan/crust/blob/crust-irc/docs/crust_irc.md

The crust_peer example works well enough as an irc client, but it has a few annoyances that need fixed for it to be usable. The biggest one is the ability to type "send nick message" instead of "send 192.168.1.23:5640 message_goes_here" and receiving messages in an irc-like format.

Entering stop should stop the example exe, but on Windows, frequently it just results in the exe hanging. If we then attempt to kill it using ctrl+C, the exe appears to have stopped (in that control is returned to the console), but it is actually still running (can be seen and killed via Task Manager).

In current implementation after a failed attempt to listen on any port, the code starts listening on a OS provided port. This means that there is no way to try a list of preferred_ports.
Either preferred_ports should be changed to have only one entry or or the code changed to handle trying multiple preferred_ports

Can we reduce the printout from CRUST, in particular the failed connections on various interfaces; or have a way to disable it; Every higher layer piles up more printout (Routing is certainly not innocent here), but CRUST really tends to produce the majority and floods the terminal for more actions on higher levels.

Ben had issues when trying to use Crust despite having read the docs (http://maidsafe.net/crust/crust/connection_manager/struct.ConnectionManager.html).

As well as cleaning up and checking that the existing comments are valid, it would be good to perhaps be a bit more explicit about when events are fired, particularly with regards to bootstrapping and the NewConnection and LostConnection events.

The input help line shown while the example is running is displayed each time after the user has entered a command. However, it can be followed by messages regarding connections being made or dropped, making it appear as though the user can't input anything any more.

We should probably either only show the help once at the start, or ensure it's always displayed again after a message is printed in the same way it's displayed after a command is entered. This would depend on the only output being from the example itself.

to make sure that the second peer uses the proper beacon port, when no value is passed as the beacon port is should take the default value.

Bootstrap method is blocking and returns endpoint it bootstrapped with. Crust also fires a new connection event even for bootstrapped endpoint. We need not to have both options here.

This is happening due to generic handling of all connection including bootstrap connections.
One potential fix will be: For bootstrap connection, only add connection to the state object if it is selected and returned as bootstrap endpoint. Also don't fire new connection event.

This will become major issue once we start doing parallel bootstrapping (Mike's PR #108).
As even after bootstrap method returns, crust will continue its parallel bootstrapping and new connection event will be fired along with keeping all tried connection in state object.

Default config file/cache file path needs to be current_exe_path.
This also need to be documented in sync with installer.

When running the crust_peer example, if the node is the first on the LAN (i.e. it manages to start listening on the beacon port and doesn't connect to any other nodes via the beaconing method) then it disregards its own bootstrap list.

Due to looping to connect to cached contacts, two client trying to connect to same local port (not listening & unoccupied) connect to each other. (TCP simultaneous connect)

Steps to reproduce:

1. Start first crust peer and close it once it starts listening.

prakash@machine:~/rust/maidsafe/crust (MAID-1136_new_bootstrap_event)$ cargo run --example crust_peer
   Compiling crust v0.1.5 (file:///home/prakash/rust/maidsafe/crust)
     Running `target/debug/examples/crust_peer`
Error reading Bootstrap file: Error { repr: Os { code: 2, message: "No such file or directory" } }. Creating "./crust_peer.bootstrap.cache".
Listening for new connections on Tcp(V4(127.0.0.1:45574)), Tcp(V4(192.168.0.10:45574)), Tcp(V6([::1]:45574)), Didn't bootstrap to an existing network - this may be the first node of a new network.
^C

Bootstrap cache will have listening endpoints added (currently unused)

prakash@machine:~/rust/maidsafe/crust (MAID-1136_new_bootstrap_event)$ cat crust_peer.bootstrap.cache 
[
  {
    "endpoint": "127.0.0.1:45574"
  },
  {
    "endpoint": "192.168.0.10:45574"
  },
  {
    "endpoint": "[::1]:45574"
  }
]prakash@machine:~/rust/maidsafe/crust (MAID-1136_new_bootstrap_event)$

2. Start first crust peer again and it can be noticed that it bootstrapped with its previous listening port.

prakash@machine:~/rust/maidsafe/crust (MAID-1136_new_bootstrap_event)$ cargo run --example crust_peer
     Running `target/debug/examples/crust_peer`
Listening for new connections on Tcp(V4(127.0.0.1:37180)), Tcp(V4(192.168.0.10:37180)), Tcp(V6([::1]:37180)), 
New BootstrapConnection to peer at Tcp(V4(192.168.0.10:45574))
1 connected node: Tcp(V4(192.168.0.10:45574))
Enter command (stop | connect <endpoint> | send <endpoint> <message>)>Bootstrapped to Tcp(V4(192.168.0.10:45574))
Got at least one bootstrap connection. Breaking bootstrap loop.

Enter command (stop | connect <endpoint> | send <endpoint> <message>)>

lsof output

 prakash@machine:~$ lsof  -i :45574
COMMAND     PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
crust_pee 16100 prakash   11u  IPv4 1603649      0t0  TCP 192.168.0.10:45574->192.168.0.10:45574 (ESTABLISHED)
crust_pee 16100 prakash   13u  IPv4 1603649      0t0  TCP 192.168.0.10:45574->192.168.0.10:45574 (ESTABLISHED)