Bring the mock quic_p2p/Network object needed to run both routing and vaults on mock network.

Decision:
https://maidsafe.slack.com/archives/C072L6WGH/p1578412061321200?thread_ts=1578409118.307500&cid=C072L6WGH

Adam Cigánek 12 minutes ago
I think taking mock-quic-p2p out of routing and making it its own crate (or part of real quic-p2p behind a feature flag) would probably clarify lot of the confusion here.

Jean-Philippe Dufraigne 8 minutes ago
Would that address your concerns @dirvine?

David Irvine 3 minutes ago
Yes @jean mostly. I would also be in favour of making all the routing mock stuff not accessible to any others right now. The visibility/api changes we make with mock for testing should not be available to others. Until we can separate that out then I would say we must make the mock flags private to routing. (edited)

Jean-Philippe Dufraigne 3 minutes ago
@dirvine would you favor the one crate solution (in quic_p2p like it is for threshold_crypto, probably simpler) or 2 crate a new test crate/repo? (edited)

David Irvine 1 minute ago
I reckon for speed and being in line with others right now the single crate is cool JP. It keeps it all together really. I also think later the mock parsec should be in parsec for the same reasons, again not changing the parsec API.

We should enable the standard set of lint settings and resolve the resulting errors.

Currently the test cases are only for node-node connection. Have some client-node test cases too.

To reproduce:

$ ./sn_node --help

Notice duplicate short flags in the output:

    -e, --external-ip <external-ip>
            External IP address of the computer on the WAN. This field is mandatory if the node is the genesis node and
            port forwarding is not available. In case of non-genesis nodes, the external IP address will be resolved
            using the Echo service
    -e, --external-port <external-port>
            External port number assigned to the socket address of the program. If this is provided, QP2p considers that
            the local port provided has been mapped to the provided external port number and automatic port forwarding
            will be skipped
...
    -l, --local-ip <local-ip>
            IP address for the listener. If none is supplied and `forward_port` is enabled, we will use IGD to realize
            the local IP address of the machine. If IGD fails the application will exit
    -l, --local-port <local-port>
            Port we want to reserve for QUIC. If none supplied we'll use the OS given random port. If external port is
            provided it means that the user is carrying out manual port forwarding and this field is mandatory. This
            will be the internal port number mapped to the process

The duplicate for -e is here:

The duplicate for -l is here:

Note that within node itself there is also this third -l flag:

    -l, --local           
            Is the node running for a local section?

So maybe this is a good option?:

• -l, --local
• -i, --local-ip <local-ip>
• -p --local-port
• -I, --external-ip <external-ip>
• -P, --external-port <external-port>

Describe the bug
Currently, someone using this crate has to depend on it as well as on the tokio crate, this is bad because

• A user should not have to depend on two crates in order to use one.
• If a user depends on a different version than this crate tokio is duplicated,
  also if the version the user depends on is a breaking change of the one qp2p does, that could create problems since tokio is a runtime.

To Reproduce

1. depend on this crate (cargo add qp2p)
2. run some code
3. realize you can't use .await syntax
4. depend on tokio (annoying)
5. If versions are incompatible: code panics in a really weird way

Expected behavior
This crate re-exports tokio and that is the runtime you use

Screenshots

[dependencies]
qp2p = "0.8.8"
tokio = { version = "~0.2", features = ["rt-threaded", "macros"] }

Desktop (please complete the following information where applicable):

• quic-p2p: 0.8.8

Additional context
I'd be happy to create the pull request for this fix and all the documentation corrections. I'll also add the relevant tokio features to this crate and give them a tokio- prefix.
In the end you should be able to use the crate like this:

qp2p = { version = "0.9.0", features = ["tokio-rt-threaded"] }

and use tokio like this:

use qp2p::rt;

#[rt::main]
async fn main() {}

or like this: (IMO less elegant but easier to adopt)

use qp2p::tokio;

#[tokio::main]
async fn main() {}

Describe the bug
I get an error, when compiling for 32-bit Linux:

   Compiling qp2p v0.10.1
error[E0308]: mismatched types
   --> /home/devel/.cargo/registry/src/github.com-1ecc6299db9ec823/qp2p-0.10.1/src/wire_msg.rs:156:45
    |
156 |         let data_len = usize::from_be_bytes([0, 0, 0, 0, bytes[2], bytes[3], bytes[4], bytes[5]]);
    |                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected an array with a fixed size of 4 elements, found one with 8 elements

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
error: could not compile `qp2p`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed
cargo build --target=i686-unknown-linux-gnu  1171,25s user 83,79s system 143% cpu 14:35,91 total

To Reproduce
I was trying to compile a Rust FFI library. My lib.rs:

use std::os::raw::c_char;
use std::ffi::CString;
use sn_api::Safe;

// Based on this tutorial: https://dev.to/verkkokauppacom/creating-an-ffi-compatible-c-abi-library-in-rust-5dji

fn xorurl_base() -> String {
    let mut safe = Safe::default();
    return safe.xorurl_base.to_string();
}

#[no_mangle]
pub extern "C" fn c_xorurl_base() -> *mut c_char {
    let rust_string: String = xorurl_base();

    // Convert the String into a CString
    let c_string: CString = CString::new(rust_string).expect("Could not convert to CString");

    // Instead of returning the CString, we return a pointer for it.
    return c_string.into_raw();
}

Expected behavior
I expect compilation without errors.

• OS: Arch Linux
• Shell: zsh
• Rust: rustc 1.49.0 (e1884a8e3 2020-12-29)
• quic-p2p crate version: 0.10.1

qp2p has declared a dependency on bytes 1.0.1, but uses function BytesMut::zeroed available only since bytes 1.2.0.

failure is officially deprecated/unmaintained

The failure crate is officially end-of-life: it has been marked as deprecated
by the former maintainer, who has announced that there will be no updates or
maintenance work on it going forward.

The following are some suggested actively developed alternatives to switch to:

• anyhow
• eyre
• fehler
• snafu
• thiserror

See advisory page for additional details.

ansi_term is Unmaintained

The maintainer has adviced this crate is deprecated and will not
receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• anstyle
• nu-ansi-term
• yansi

See advisory page for additional details.

Will quic-p2p replace crust or ẁill it be added as an additional protocol, respectively what are the plans in the future for both of them?

Greetings,
Chris

Provide implementation for https://github.com/maidsafe/quic-p2p/blob/8b4c6af6163ddc1ee99c46c39cc4a79a86751c71/src/config.rs#L51-L52 and https://github.com/maidsafe/quic-p2p/blob/8b4c6af6163ddc1ee99c46c39cc4a79a86751c71/src/config.rs#L58

spin is no longer actively maintained

The author of the spin crate does not have time or interest to maintain it.

Consider the following alternatives (both of which support no_std):

• conquer-once
• lock_api (a subproject of parking_lot)
  • spinning_top spinlock crate built on lock_api

See advisory page for additional details.

Might be needed to handle malicious / malfunctioning proxies to avoid attempts to connect to them again and again.

Consider addressing comment #95 (comment)
where the manual select is not necessary since the select! macro does the same thing.

See https://github.com/maidsafe/quic-p2p/pull/107/checks?check_run_id=677634467#step:8:533

Extract from logs

  18: std::panic::catch_unwind
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd\src\libstd\panic.rs:394
  19: test::run_test_in_process
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd\/src\libtest\lib.rs:542
  20: test::run_test::run_test_inner::{{closure}}
             at /rustc/8d69840ab92ea7f4d323420088dd8c9775f180cd\/src\libtest\lib.rs:451
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    tests::echo_service

test result: FAILED. 21 passed; 1 failed; 2 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '-p quic-p2p --lib'
##[error]The process 'C:\Rust\.cargo\bin\cargo.exe' failed with exit code 101

Testing bootstrap_node and client_node with IP V4 is OK:

Command server side:

$ RUST_LOG=bootstrap_node=info target/debug/examples/bootstrap_node --ip 116.203.42.154 --port 5483 --expected_conns 1
[2020-01-16T10:25:10Z INFO  bootstrap_node] QuicP2p started on 116.203.42.154:5483
Our connection info:
{"peer_addr":"116.203.42.154:5483","peer_cert_der":[48,130,1,79,48,129,246,160,3,2,1,2,2,1,42,48,10,6,8,42,134,72,206,61,4,3,2,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,34,24,15,49,57,55,53,48,49,48,49,48,48,48,48,48,48,90,24,15,52,48,57,54,48,49,48,49,48,48,48,48,48,48,90,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,89,48,19,6,7,42,134,72,206,61,2,1,6,8,42,134,72,206,61,3,1,7,3,66,0,4,91,52,55,9,205,180,86,71,19,143,185,160,85,128,200,145,32,1,139,236,126,147,238,150,201,247,156,78,134,85,191,203,66,165,82,182,107,66,35,48,112,31,63,34,148,197,249,199,128,74,218,3,22,108,163,38,76,61,42,103,252,122,145,196,163,27,48,25,48,23,6,3,85,29,17,4,16,48,14,130,12,77,97,105,100,83,65,70,69,46,110,101,116,48,10,6,8,42,134,72,206,61,4,3,2,3,72,0,48,69,2,32,39,74,203,148,153,231,248,148,140,39,99,190,215,247,208,104,227,213,216,96,60,226,192,3,79,173,226,123,165,20,112,211,2,33,0,215,21,57,239,21,254,177,166,30,28,24,60,175,183,77,126,147,127,98,121,105,57,175,52,126,210,63,230,189,76,66,37]}

[2020-01-16T10:25:49Z INFO  bootstrap_node] 1 connections collected, triggering the test
[2020-01-16T10:25:49Z WARN  bootstrap_node] Unexpected event: SentUserMessage { peer_addr: V4(116.203.42.154:443), msg: b"\0\0\0\0\x01\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0t\xcb*\x9a\xbb\x01S\x01\0\0\0\0\0\00\x82\x01O0\x81\xf6\xa0\x03\x02\x01\x02\x02\x01*0\n\x06\x08*\x86H\xce=\x04\x03\x020!1\x1f0\x1d\x06\x03U\x04\x03\x0c\x16rcgen self signed cert0\"\x18\x0f19750101000000Z\x18\x0f40960101000000Z0!1\x1f0\x1d\x06\x03U\x04\x03\x0c\x16rcgen self signed cert0Y0\x13\x06\x07*\x86H\xce=\x02\x01\x06\x08*\x86H\xce=\x03\x01\x07\x03B\0\x04\xf2w\x95\xc8\xc2\x8c\x0e\xc0\x0e\xd6\xe7>\x18l\t\x04b\x87\xdery\x0c\x1ch\x1e\x9d\x7f>\xd4\xefd\xc2\xeb\xc5\n;.\xa3\x89`\xd8\x84\x9cV\xc8\xb9\xe2\xc3\xfcm\xa2P\xf8t\x9e9Y\x9a\x01\x921\x19\xaba\xa3\x1b0\x190\x17\x06\x03U\x1d\x11\x04\x100\x0e\x82\x0cMaidSAFE.net0\n\x06\x08*\x86H\xce=\x04\x03\x02\x03H\00E\x02!\0\xad\xd2\xc8F\x81'\xde\x81N0\xf8\xc5]\x1fz\"\x82pe\xe7\xe4\xb8U\x12\x12\x1f\\\xf6\xa6p\x0fT\x02 \r\x92\x0f\x9c\xe0\xba\x9e-\x06\xec\x01\xbb\x11\x8b;\x01\x99j`\xe3B\x96\x83>\xcb7\xb7?x8\xef<", token: 0 }
[2020-01-16T10:25:49Z WARN  bootstrap_node] Unexpected event: NewMessage { peer_addr: V4(116.203.42.154:443), msg: b"\x01\x02\x03" }
[2020-01-16T10:26:39Z WARN  bootstrap_node] Unexpected event: ConnectionFailure { peer_addr: V4(116.203.42.154:443), err: ConnectionCancelled }

Command client side:

$ RUST_LOG=client_node=info target/debug/examples/client_node --hard-coded-contacts '[{"peer_addr":"116.203.42.154:5483","peer_cert_der":[48,130,1,79,48,129,246,160,3,2,1,2,2,1,42,48,10,6,8,42,134,72,206,61,4,3,2,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,34,24,15,49,57,55,53,48,49,48,49,48,48,48,48,48,48,90,24,15,52,48,57,54,48,49,48,49,48,48,48,48,48,48,90,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,89,48,19,6,7,42,134,72,206,61,2,1,6,8,42,134,72,206,61,3,1,7,3,66,0,4,91,52,55,9,205,180,86,71,19,143,185,160,85,128,200,145,32,1,139,236,126,147,238,150,201,247,156,78,134,85,191,203,66,165,82,182,107,66,35,48,112,31,63,34,148,197,249,199,128,74,218,3,22,108,163,38,76,61,42,103,252,122,145,196,163,27,48,25,48,23,6,3,85,29,17,4,16,48,14,130,12,77,97,105,100,83,65,70,69,46,110,101,116,48,10,6,8,42,134,72,206,61,4,3,2,3,72,0,48,69,2,32,39,74,203,148,153,231,248,148,140,39,99,190,215,247,208,104,227,213,216,96,60,226,192,3,79,173,226,123,165,20,112,211,2,33,0,215,21,57,239,21,254,177,166,30,28,24,60,175,183,77,126,147,127,98,121,105,57,175,52,126,210,63,230,189,76,66,37]}]'
CliArgs { quic_p2p_opts: Config { hard_coded_contacts: {NodeInfo { peer_addr: V4(116.203.42.154:5483), peer_cert_der: [48, 130, 1, 79, 48, 129, 246, 160, 3, 2, 1, 2, 2, 1, 42, 48, 10, 6, 8, 42, 134, 72, 206, 61, 4, 3, 2, 48, 33, 49, 31, 48, 29, 6, 3, 85, 4, 3, 12, 22, 114, 99, 103, 101, 110, 32, 115, 101, 108, 102, 32, 115, 105, 103, 110, 101, 100, 32, 99, 101, 114, 116, 48, 34, 24, 15, 49, 57, 55, 53, 48, 49, 48, 49, 48, 48, 48, 48, 48, 48, 90, 24, 15, 52, 48, 57, 54, 48, 49, 48, 49, 48, 48, 48, 48, 48, 48, 90, 48, 33, 49, 31, 48, 29, 6, 3, 85, 4, 3, 12, 22, 114, 99, 103, 101, 110, 32, 115, 101, 108, 102, 32, 115, 105, 103, 110, 101, 100, 32, 99, 101, 114, 116, 48, 89, 48, 19, 6, 7, 42, 134, 72, 206, 61, 2, 1, 6, 8, 42, 134, 72, 206, 61, 3, 1, 7, 3, 66, 0, 4, 91, 52, 55, 9, 205, 180, 86, 71, 19, 143, 185, 160, 85, 128, 200, 145, 32, 1, 139, 236, 126, 147, 238, 150, 201, 247, 156, 78, 134, 85, 191, 203, 66, 165, 82, 182, 107, 66, 35, 48, 112, 31, 63, 34, 148, 197, 249, 199, 128, 74, 218, 3, 22, 108, 163, 38, 76, 61, 42, 103, 252, 122, 145, 196, 163, 27, 48, 25, 48, 23, 6, 3, 85, 29, 17, 4, 16, 48, 14, 130, 12, 77, 97, 105, 100, 83, 65, 70, 69, 46, 110, 101, 116, 48, 10, 6, 8, 42, 134, 72, 206, 61, 4, 3, 2, 3, 72, 0, 48, 69, 2, 32, 39, 74, 203, 148, 153, 231, 248, 148, 140, 39, 99, 190, 215, 247, 208, 104, 227, 213, 216, 96, 60, 226, 192, 3, 79, 173, 226, 123, 165, 20, 112, 211, 2, 33, 0, 215, 21, 57, 239, 21, 254, 177, 166, 30, 28, 24, 60, 175, 183, 77, 126, 147, 127, 98, 121, 105, 57, 175, 52, 126, 210, 63, 230, 189, 76, 66, 37] }}, port: None, ip: None, max_msg_size_allowed: None, idle_timeout_msec: None, keep_alive_interval_msec: None, our_complete_cert: None, bootstrap_cache_dir: None, our_type: Node } }
[2020-01-16T10:25:49Z INFO  client_node] Peer started
[2020-01-16T10:25:49Z INFO  client_node] Connected with: 116.203.42.154:5483
[2020-01-16T10:25:49Z INFO  client_node] Connected to bootstrap node. Waiting for other node contacts...
[2020-01-16T10:25:49Z WARN  client_node] Unexpected event: SentUserMessage { peer_addr: V4(116.203.42.154:5483), msg: b"\x01\x02\x03", token: 0 }

But using IP V6 is not OK:

Command server side:

$ RUST_LOG=bootstrap_node=info target/debug/examples/bootstrap_node --ip 2a01:4f8:1c1c:9ca9::1 --port 5483 --expected_conns 1
[2020-01-16T10:08:00Z INFO  bootstrap_node] QuicP2p started on [2a01:4f8:1c1c:9ca9::1]:5483
Our connection info:
{"peer_addr":"[2a01:4f8:1c1c:9ca9::1]:5483","peer_cert_der":[48,130,1,79,48,129,246,160,3,2,1,2,2,1,42,48,10,6,8,42,134,72,206,61,4,3,2,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,34,24,15,49,57,55,53,48,49,48,49,48,48,48,48,48,48,90,24,15,52,48,57,54,48,49,48,49,48,48,48,48,48,48,90,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,89,48,19,6,7,42,134,72,206,61,2,1,6,8,42,134,72,206,61,3,1,7,3,66,0,4,168,14,159,37,80,240,21,161,192,247,190,83,160,186,190,150,88,205,200,119,158,27,39,20,206,200,61,242,161,164,18,12,209,241,227,7,196,151,66,182,88,243,157,64,253,72,135,78,199,201,204,16,60,169,120,57,48,141,114,1,171,73,205,93,163,27,48,25,48,23,6,3,85,29,17,4,16,48,14,130,12,77,97,105,100,83,65,70,69,46,110,101,116,48,10,6,8,42,134,72,206,61,4,3,2,3,72,0,48,69,2,32,87,222,18,184,16,88,216,243,242,37,214,89,92,211,2,88,24,221,168,28,147,43,137,170,45,53,129,159,18,221,224,202,2,33,0,244,10,245,169,45,170,26,97,66,133,58,99,5,53,200,49,133,150,102,26,223,32,57,147,99,26,198,218,10,194,160,148]}

Command client side:

$ RUST_LOG=client_node=info target/debug/examples/client_node --hard-coded-contacts '[{"peer_addr":"[2a01:4f8:1c1c:9ca9::1]:5483","peer_cert_der":[48,130,1,79,48,129,246,160,3,2,1,2,2,1,42,48,10,6,8,42,134,72,206,61,4,3,2,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,34,24,15,49,57,55,53,48,49,48,49,48,48,48,48,48,48,90,24,15,52,48,57,54,48,49,48,49,48,48,48,48,48,48,90,48,33,49,31,48,29,6,3,85,4,3,12,22,114,99,103,101,110,32,115,101,108,102,32,115,105,103,110,101,100,32,99,101,114,116,48,89,48,19,6,7,42,134,72,206,61,2,1,6,8,42,134,72,206,61,3,1,7,3,66,0,4,168,14,159,37,80,240,21,161,192,247,190,83,160,186,190,150,88,205,200,119,158,27,39,20,206,200,61,242,161,164,18,12,209,241,227,7,196,151,66,182,88,243,157,64,253,72,135,78,199,201,204,16,60,169,120,57,48,141,114,1,171,73,205,93,163,27,48,25,48,23,6,3,85,29,17,4,16,48,14,130,12,77,97,105,100,83,65,70,69,46,110,101,116,48,10,6,8,42,134,72,206,61,4,3,2,3,72,0,48,69,2,32,87,222,18,184,16,88,216,243,242,37,214,89,92,211,2,88,24,221,168,28,147,43,137,170,45,53,129,159,18,221,224,202,2,33,0,244,10,245,169,45,170,26,97,66,133,58,99,5,53,200,49,133,150,102,26,223,32,57,147,99,26,198,218,10,194,160,148]}]'
CliArgs { quic_p2p_opts: Config { hard_coded_contacts: {NodeInfo { peer_addr: V6([2a01:4f8:1c1c:9ca9::1]:5483), peer_cert_der: [48, 130, 1, 79, 48, 129, 246, 160, 3, 2, 1, 2, 2, 1, 42, 48, 10, 6, 8, 42, 134, 72, 206, 61, 4, 3, 2, 48, 33, 49, 31, 48, 29, 6, 3, 85, 4, 3, 12, 22, 114, 99, 103, 101, 110, 32, 115, 101, 108, 102, 32, 115, 105, 103, 110, 101, 100, 32, 99, 101, 114, 116, 48, 34, 24, 15, 49, 57, 55, 53, 48, 49, 48, 49, 48, 48, 48, 48, 48, 48, 90, 24, 15, 52, 48, 57, 54, 48, 49, 48, 49, 48, 48, 48, 48, 48, 48, 90, 48, 33, 49, 31, 48, 29, 6, 3, 85, 4, 3, 12, 22, 114, 99, 103, 101, 110, 32, 115, 101, 108, 102, 32, 115, 105, 103, 110, 101, 100, 32, 99, 101, 114, 116, 48, 89, 48, 19, 6, 7, 42, 134, 72, 206, 61, 2, 1, 6, 8, 42, 134, 72, 206, 61, 3, 1, 7, 3, 66, 0, 4, 168, 14, 159, 37, 80, 240, 21, 161, 192, 247, 190, 83, 160, 186, 190, 150, 88, 205, 200, 119, 158, 27, 39, 20, 206, 200, 61, 242, 161, 164, 18, 12, 209, 241, 227, 7, 196, 151, 66, 182, 88, 243, 157, 64, 253, 72, 135, 78, 199, 201, 204, 16, 60, 169, 120, 57, 48, 141, 114, 1, 171, 73, 205, 93, 163, 27, 48, 25, 48, 23, 6, 3, 85, 29, 17, 4, 16, 48, 14, 130, 12, 77, 97, 105, 100, 83, 65, 70, 69, 46, 110, 101, 116, 48, 10, 6, 8, 42, 134, 72, 206, 61, 4, 3, 2, 3, 72, 0, 48, 69, 2, 32, 87, 222, 18, 184, 16, 88, 216, 243, 242, 37, 214, 89, 92, 211, 2, 88, 24, 221, 168, 28, 147, 43, 137, 170, 45, 53, 129, 159, 18, 221, 224, 202, 2, 33, 0, 244, 10, 245, 169, 45, 170, 26, 97, 66, 133, 58, 99, 5, 53, 200, 49, 133, 150, 102, 26, 223, 32, 57, 147, 99, 26, 198, 218, 10, 194, 160, 148] }}, port: None, ip: None, max_msg_size_allowed: None, idle_timeout_msec: None, keep_alive_interval_msec: None, our_complete_cert: None, bootstrap_cache_dir: None, our_type: Node } }

Server is not reached and connection info is not sent back to client.

My UFW configuration allows 5483/udp for both IP V4 and IP V6:

$ ufw status | grep 5483
5483/udp                   ALLOW       Anywhere
5483/udp (v6)              ALLOW       Anywhere (v6)

=> Return unsent message

Currently we use a per-node certificate authority where we require the node certificate to be passed to us via a side-channel. Even this mechanism is going away soon via #91. We should add a support for proper certificate authorities so users could provide certificates from established authorities. Eventually in the long term, we might create a safe-network cert authority and support that as well.

Problem

I have been trying to get a simple file send happening between two peers on a local network and have been unable to make a connection.
It works fine when both sender and receiver are on the same computer but when i use two computers it simply doesn't connect
I don't actually know if this is a bug or me not understanding how this should be done.
Both computers should have no firewall and are on the same network switch.

Example

Client

async fn client( addr:&String,filePath:&str) -> Result<(), Error> {

    let mut file= std::fs::File::open(filePath)?;
    
    let serveraddr=addr.parse().expect("failed parsing server ip");

    let mut config = Config::default();
    config.ip = Some(IpAddr::V4(Ipv4Addr::LOCALHOST));
    config.port=Some(0);

    let mut quic_p2p =qp2p::QuicP2p::with_config(Some(config), Default::default(), true)?;

    //connect to the server
    let peer2= quic_p2p.new_endpoint().expect("failed creating endpoint");
    println!(" CLIENT HOSTING AT: {}",peer2.our_endpoint().unwrap());
    println!("Client connecting to : {}",serveraddr);
    let mut connection= peer2.connect_to(&serveraddr).await?;
    //send files 
}

Server

async fn server_recv_file(host_ip: &String) -> Result<(),Error> {
    println!("Hello, world!");
    
    let mut file=std::fs::File::create("./out")?;

    let con=qp2p::QuicP2p::new()?;
    
    let mut config = Config::default();
    let addr:Ipv4Addr=host_ip.parse().expect("could not parse input ip addr 'x.x.x.x'");
    config.ip = Some(addr.into());
    config.port=Some (5500);
    let mut quic_p2p = QuicP2p::with_config(Some(config.clone()), Default::default(), true)?;
    let server=quic_p2p.new_endpoint()?;
    println!("HOSTING SERVER AT: {}",server.our_endpoint().unwrap());
    //configure listener
    let mut listener=server.listen()?;
    let mut a=listener.next().await.unwrap();
    println!("recived connection");
    //receive `files`
}

We are seeing a problem in brb_node_qp2p where it sometimes drops a packet and BRB process halts. (code here)

I was able to reproduce this with a simple test case which you can run. Just clone and build qp2p_experiments repo.

I am unsure whether the problem exists in qp2p lib or in our usage of it.

You will see in the test case, that we are using send_uni, and are calling connect_to() and new_endpoint() each time we want to send a packet to our peer.

We listen for connections and packets like so:

    while let Some(mut msgs) = conns.next().await {
        println!("Received a connection from {}", msgs.remote_addr());
        while let Some(msg) = msgs.next().await {
            ...
            println!("Got message: {}", msg_str);
        }
        println!("done with msgs.");
    }

After a random-ish number of packets exchanged (always under 5000 so far), this loop fails. In particular, msgs.next() returns None immediately after a connection is received, so the interior of inner while loop never executes.

It seems as though a connection is made and then immediately closed. but.... why?

So I guess the question would be: is this correct behavior of qp2p, and if so, how do we code this loop better?

Here is an example run/output:

Node A

$ cargo run --bin node_uni create
Listening for messages on 127.0.0.1:10000
...
Received a connection from 127.0.0.1:48286
Got message: 343
Sent message: 344 to: 127.0.0.1:10001
done with msgs.  cnt = 344
Received a connection from 127.0.0.1:38339
Got message: 345
Sent message: 346 to: 127.0.0.1:10001
done with msgs.  cnt = 346
Received a connection from 127.0.0.1:43818
Got message: 347
Sent message: 348 to: 127.0.0.1:10001
done with msgs.  cnt = 348
Received a connection from 127.0.0.1:51354
done with msgs.  cnt = 348

Node B

$ cargo run --bin node_uni
...
Received a connection from 127.0.0.1:54098
Got message: 344
Sent message: 345 to: 127.0.0.1:10000
done with msgs.  cnt = 345
Received a connection from 127.0.0.1:32864
Got message: 346
Sent message: 347 to: 127.0.0.1:10000
done with msgs.  cnt = 347
Received a connection from 127.0.0.1:55820
Got message: 348
Sent message: 349 to: 127.0.0.1:10000
done with msgs.  cnt = 349

Notice that on both nodes, the normal pattern is: Received, Got, Sent, Done. However for Node A, the final sequence before it halts is: Received, Done.

btw. running both nodes with RUST_LOG="qp2p=warn,quinn=warn", there are no warnings or errors logged. Running with RUST_LOG="qp2p=trace,quinn=trace" dumps a ton of trace info but no smoking gun for me.

Use this to pass config and other options to quic-p2p.

I am searching guideline about peer discovery support in qp2p, is it supported by this crate?

Connection is just a trivial wrapper around quinn::Connection which itself is cheaply Cloneable, so Connection should be too.

Test cases for:

0. A faulty peer (node or client) that doesn't successfully complete handshake within a give period of time does not keep our resources unresolved with tokio forever and the incomplete connection is severed.
1. Check for scenarios that a faulty peer can get us into and make sure they don't cause us harm

webpki: CPU denial of service in certificate path building

When this crate is given a pathological certificate chain to validate, it will
spend CPU time exponential with the number of candidate certificates at each
step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

This was previously reported in
<briansmith/webpki#69> and re-reported recently
by Luke Malinowski.

rustls-webpki is a fork of this crate which contains a fix for this issue
and is actively maintained.

See advisory page for additional details.

Currently it's impossible to use err-derive's source attribute on variants that contain quic-p2p's Error because of this. It works with the real quic-p2p, but not with the mock.

Hello,
I can't get the chat example running since ourinfo always returns an error, I can't copy any information to use the addpeer command

>> ourinfo
Error getting ourinfo: There's no endpoint echo server to ask. Current network configuration

Do I need to add a certain configuration on startup?

Thanks in advance

It probably needs to be sent to the event channel when the QuicP2P handle is being dropped.

Have an API for the user to pass the bootstrap cache to be used for bootstrap. Have a flag to specify if to use this instead or in addition to the bootstrap cache file that may be found on the disk.

xml-rs is Unmaintained

xml-rs is a XML parser has open issues around parsing including integer
overflows / panics that may or may not be an issue with untrusted data.

Together with these open issues with Unmaintained status xml-rs
may or may not be suited to parse untrusted data.

Alternatives

• quick-xml

See advisory page for additional details.

Provide an API to bootstrap. This will first use the bootstrap cache followed by hard-coded contacts to bootstrap off a proxy. Once the bootstrap with a proxy is successful we should kill all the ongoing bootstrap attempts to other proxies.

Not necessarily a bug, but I just wanted to make sure since I'm new in Rust. On line 218, function max_transport_config, file configs.rs. the code looks like this:

let _ = config.max_idle_timeout(Some(idle_timeout)).ok();

But max_idle_timeout's documentation, when it comes to Durations, states that it should look more like this:

let _ = config.max_idle_timeout(Some(idle_timeout).try_into()?);

With the change above Pycharm does not complain anymore for mismatched_types. As I said, not a bug, just looking to discuss this with someone that knows better.

Presently, QuicP2p::with_config() contains this logic:

        let (port, allow_random_port) = cfg
            .port
            .map(|p| (p, false))
            .unwrap_or((DEFAULT_PORT_TO_TRY, true));

Thus allow_random_port is set to false if caller specifies a port, and is set to true otherwise.

However, esp when using ::send_uni(), a caller may need to be listening on one port and sending on another. So it can make sense to specify a port for listening, and then request a random port for sending.

Presently, if the caller specifies a known port in config, eg 10000 and then calls ::new_endpoint() twice, the second call will fail/error because the port is already in use. That seems a little bit broken-by-design.

As such, I am thinking that perhaps new_endpoint() should take an Option argument that allows to override the config defaults. Or failing that, a way to specify in the config "random port for any endpoints after the first".

The Overview section of README.md has a link to the Version Negotiation section. It was written in May 2017:
IETF draft specification - https://tools.ietf.org/html/draft-ietf-quic-transport-03#section-7.1

This document has "Expires November 22, 2017" written on all of its pages (76 pages in total).

The most up to date IETF draft I found is here: https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-6. I've changed the anchored section since Version Negotiation is now in section 6. This draft was published less than a month ago (April 23, 2019) and has "Expires October 25, 2019" written on all of its pages (143 pages in total).

There could be consequences if anyone relies on the information in this obsolete document (especially if they are writing code).

For users of an older version it's difficult to see that the package is continued under a different name. Therefore I would propose to release a 0.7.1 on crates.io with a readme which links to the new package.

rustls::ConnectionCommon::complete_io could fall into an infinite loop based on network input

If a close_notify alert is received during a handshake, complete_io
does not terminate.

Callers which do not call complete_io are not affected.

rustls-tokio and rustls-ffi do not call complete_io
and are not affected.

rustls::Stream and rustls::StreamOwned types use
complete_io and are affected.

See advisory page for additional details.

Currently, only the NewMessage Event is handled, with a placeholder for the rest of event types:
https://github.com/maidsafe/quic-p2p/blob/f0f93205349355e610b057ca2809b8e7c30df8e0/src/event.rs#L71
We need to show relevant information there.

Related to #28.

directories is unmaintained, use directoriess-next instead

The directories crate is not maintained any more;
use directories-next instead.

See advisory page for additional details.

Describe the bug

As described in this thread on the forum, a few community members are running into an issue with igd.

[sn_node] INFO [src\endpoint.rs:242] IGD request failed: Could not find the gateway device for IGD - IgdSearch(IoError(Custom { kind: TimedOut, error: "search timed out" }))
Cannot start node due to error: Routing(Network(IgdNotSupported))
[sn_node] ERROR [src/bin/sn_node.rs:118] Cannot start node due to error: Routing(Network(IgdNotSupported))

At first we thought it was being produced by incompatible CLI arguments, but once I got the full log output, on further inspection is seems to be caused by a failure in igd timing out when calling search_gateway() with the default arguments. This is something that worked in the past for me and others, but no longer does.

Perhaps it was caused by the igd version bump? Or maybe the documentation on the usage of --local-ip needs rewording, but in any case, a few people are seeing the same thing it seems

To Reproduce

sn_node --first --local-ip <non local-host local-ip>

Expected behavior
The node should start as expected and not error out.

Desktop (please complete the following information where applicable):

• OS: Windows 10, but also observed on Manjaro Linux
• Shell: Powershell
• quic-p2p crate version: sn_node 0.28.0 built with qp2p 0.9.22

Hey,
I am now trying to setup multiple nodes with slightly different, non-default setups where I want to save the cert,...
When trying to use Config::read_or_construct_default I realized that I couldn't specify the Dirs as it is inside a private/pub(crate) module and isn't made public in lib.rs too.
Is this a bug or is there a different intended way to use this function?

Thanks in advance,
Chris

net2 crate has been deprecated; use socket2 instead

The net2 crate has been deprecated
and users are encouraged to considered socket2 instead.

See advisory page for additional details.

The code has some TODOs and FIXMEs that can (or at-least needs to be analysed if they can) occur in some edge cases. Fix these

Currently (for the sake of quickness and simplicity) the crate only contacts the 1st hard-coded-contact for echo service. Discuss how many do we need to contact.

Contacting just one is problematic if they are faulty (don't respond or worse respond wrongly).

0. Work out how do we trust the results specially given that for some routers (with symmetric NATs) different peers might see us differently (different Endpoints - EPs) and validly so.
1. This should not generally happen when we are port forwarded but it has happened in the past for that too where the incoming connections on a forwarded port reaches the local EP but a new outgoing from the same local EP uses a different ephemeral mapping on the router.
2. How many results to collate/collect and how to work them our before we trust it ?

Currently SerialisableCertificate implements ToString and FromStr using base64 encoding. Since this is user-facing data (stored in the config file), we should use z-base-32 encoding for consistency across the SAFE project.

In response to:

When UPnP is unavailable, manual port-forwarding may be necessary to establish incoming connectivity.

Is there an example of how to route traffic between two peers over a third-party “relay” peer? Using qp2p.

Something like TURN...

Potential segfault in localtime_r invocations

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

Workarounds

No workarounds are known.

References

• time-rs/time#293

See advisory page for additional details.