Can not insert two different type of protocol to service.

https://github.com/nervosnetwork/p2p/blob/master/src/service/event.rs#L71

Can't forward events to a channel because of the lifetime, use Arc to instead.

PR later.

The handle_error in trait ServiceHandle, using io::Error for its error type.
It better to have a more clear error defined to distinguish what has happened in p2p framework.
For example, we need a special kind of error type to show Connected to the connected node.

• A name for crate.io
• English introduction #50
• English module doc
• Is there any API that need to modify, or where need to refactor on a large scale? @TheWaWaR
• Support /dns4/example/tcp/1337 to dial and listen #43

Hi there,

First of all, thanks for the lib.
I'm able to connect to different peers, then send messages from one to another.
One thing I couldn't achieve so far is, to use a the underlying stream (or substream) in order to forward the data via (io::copy()), would is this possible?

Thank you.

package sent by server can not reach client.

In ServiceBuilder, if the timeout is set to 0:

        let mut app_service = ServiceBuilder::default()
            .key_pair(key_pair)
            .timeout(std::time::Duration::new(0, 0))
            .build(AppServiceHandle);

The dialing always fails.

If the timeout is set to very large, e.g.,

        let mut app_service = ServiceBuilder::default()
            .key_pair(key_pair)
            .timeout(std::time::Duration::new(u64::MAX, 0))
            .build(AppServiceHandle);

The process panicked because of the error:

thread 'main' panicked at 'overflow when adding duration to instant', library/std/src/time.rs:368:33

The Server/Client is confused which is hard to tell that the node itself is server-side or a peer is server-side. Inbound/Outbound is a more clear term.

Description

Unable to open protocol randomly, especially when the client only has limited CPU resources.

This issue was introduced since PR 288: fix: fix some msg left on buffer.

Reason

• [1] When client create a Session and fetch messages from it, the follow code was running:

  tentacle/yamux/src/session.rs

  Lines 627 to 628 in 56c64b6

  	is_pending &= self.recv_unbound_events(cx)?.is_pending();
  	is_pending &= self.recv_events(cx)?.is_pending();

• [2] When client want to open a protocol, the follow code was running concurrently with [1]:

  tentacle/tentacle/src/session.rs

  Lines 321 to 331 in 56c64b6

  	let task = async move {
  	let handle = match control.open_stream().await {
  	Ok(handle) => handle,
  	Err(e) => {
  	debug!("session {} open stream error: {}", id, e);
  	return Err(io::ErrorKind::BrokenPipe.into());
  	}
  	};
  	client_select(handle, proto_info).await
  	};
  	self.select_procedure(task);

  We step into those functions, we could found there are two frames would be sent:

  [3] First:
  

  tentacle/yamux/src/stream.rs

  Lines 177 to 180 in 56c64b6

  	let frame = Frame::new_window_update(flags, self.id, delta);
  	self.unbound_event_sender
  	.unbounded_send(StreamEvent::Frame(frame))
  	.map_err(|_| Error::SessionShutdown)

  [4] Second:
  

  tentacle/tentacle/src/protocol_select/mod.rs

  Line 155 in 56c64b6

  socket.send(proto_info.encode()).await?;

  
  

  tentacle/yamux/src/stream.rs

  Line 132 in 56c64b6

  if let Err(e) = self.event_sender.try_send(event) {

• The above two pieces of code are running concurrently.

  If line 627 of [1] is done before executing line 178 in [3] and line 115 in [4] is done before executing line 628 of [1].

  The client will send the Data frame before WindowUpdate frame.

  So the server will drop Data frame without do anything.
  

  tentacle/yamux/src/session.rs

  Lines 430 to 433 in 56c64b6

  	} else {
  	// TODO: stream already closed ?
  	false
  	}

  Then the server will open the protocol with WindowUpdate frame:
  

  tentacle/yamux/src/session.rs

  Line 394 in 56c64b6

  debug!("[{:?}] Accept a stream id={}", self.ty, stream_id);

  But the server will never reply to the client.
  

  tentacle/tentacle/src/protocol_select/mod.rs

  Lines 157 to 163 in 56c64b6

  	let (raw_remote_info, socket) = socket.into_future().await;
  	let mut remote_info = match raw_remote_info {
  	Some(info) => match ProtocolInfo::decode(&info?) {
  	Some(info) => info,
  	None => return Err(io::ErrorKind::InvalidData.into()),
  	},

  So, at last, a ProtocolSelectError(Elapsed()) will be thrown.

Reproduce

• Append ::std::thread::sleep(::std::time::Duration::from_millis(300)); after line 627 in [1].

• Append ::tokio::time::delay_for(::tokio::time::Duration::from_millis(100)).await; after line 328 in [2].

• Run CKB Integration Tests Spec PoolReconcile.

  The follow code will be panicked frequently.

      info!("Connect node0 to node1");
      node0.connect(node1);
  
      waiting_for_sync(nodes);

• ERROR tentacle::session stream send back error: SendError("...")
• ERROR tentacle::session session send to sub stream error: send failed because receiver is gone
• WARN tentacle::service timer is shutdown
• WARN tentacle::substream protocol [2] close because of extern network
• WARN tentacle_secio::codec::secure_stream send message error: Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }

For case like #218 will cause serious bug.

Checkout the return result, if error give a trace log message.

tokio/bytes upgrade to 1.0

PR #293

TargetSession/TargetProtocol change

Currently, these two enumerated types under multi will force users to save all known session/protocol ids and specify them accurately, otherwise, they cannot be selectively broadcast, but this is not a good decision.

There are two proposals(mutually exclusive):

1. Add a tag like Exclude(HashSet<ID>), it can remove some known options, but you don’t need to know all the options(can manually control the sending sequence)
2. Change Multi(Vec<SessionId>) to Filter(Box<Fn(ID) -> bool + send + ‘static>), also achieved the purpose of flexibility(can't manually control the sending sequence )

Remove the deprecated event output mode

PR #293

Remove flutbuffer codec

PR #293

Extract core crate

Separate runtime encapsulation and transport layer into one library, and tentacle as a high-level encapsulation framework

Based on this design, it may be possible to implement a tentacle client to cover #205

Low priority, will not break API, can be done after release 0.4

https://github.com/libp2p/rust-libp2p

multi code table：

https://github.com/multiformats/multicodec/blob/master/table.csv

if we want to use tcp with tls, the current implementation cannot be expressed, we need to add protocol support according to the registry by ourselves

A tentacle-multiaddr crate need to implement

With the use of Multiaddr, the official itself has also found some problems, and there are problems with their own descriptions that are missing and inaccurate, and there are proposals to solve them by some means.

Parity In the case that the proposal has not yet passed, a non-standard protocol such as x-parity-ws has been added for practical needs.

Now, we have to rethink, what are our real needs for this increasingly complex specification, and whether we need to really go further and further with non-standard or complex standards.

ref: multiformats/multiaddr#87
ref: libp2p/rust-libp2p#1093

I found a stituation: in tls mod, using correct tls-certificate, the client end could reconnect to server many many times. But after any bad node using error certifacte and occur tls-handshake error, the good node can't reconnect forever.

For reproducing error, I write a ut https://github.com/Pencil-Yao/tentacle/blob/tls-reconnect-err/tentacle/tests/test_tls_reconnect.rs. In the ut, node0 and node1 is ok, node2 use error certificate, and test_tls_reconnect_wrong can not be done.

可能与 #205 有关。

我用io::copy转发数据，发现StreamHandle在另一端调用shutdown后read总是返回一个unexpectedeof，但Tokio的TcpStream在这种情况下返回Ok(0)，io::copy也依赖该行为，是有意这样设计的吗？

测试代码-yamux
测试代码-tokio

Related PR: #94

I was looking into the rust-libp2p but soon I realized it is quite unlikely to figure out what they are doing, as the code is written like a hell - overwhelming abstraction, stacked state machines...

Later I happend to find this repo, much smaller, and kind of neat. However, after reading the code, I believe there are something wrong in your secio implementation.

1. secio should be message oriented. In your code, it is not. Messages will be combined as big as the input buffer provided
2. Don't really get why having channels in secio. Code could be very simple if making SecureStream 'AsyncRead/AsyncWrite', in this case we don't have to pass frames with channel. Furthermore the task running SecureStream.next can be eliminated

I'm quite new to rust, but I wonder if the async code in rust has to be written like this: poll in poll with state machine? I tend to believe code should be written in a better way after we have the formal async/await. Otherwise, it is a huge burden for rusters to write and maintain code written like this.

Of course I can make a pull request later if you like, just let me know...

Handle the collection errors when reading data:

But not when writing:

Allow messages encoded by molecule. Library user can choose different serialization format via cargo feature.

As you talked about Handshake process in "Implementing a a p2p network framework", this library has not implemented the certificate mechanism, which means that man-in-the-middle attacks are possible.

Do you have a plan to do this task?

In the case of overweight tasks and poor machine performance, this problem will occur in the original code, #150 has been resolved, but the test can not reproduce the problem

base：tokio-rs/tokio#4037 which resolves tokio-rs/tokio#4034

code：

QUIC looks better than TCP about performance and security.

Related Issue citahub/rfcs#1

• The 0.1 version has an error not reported to the user #54
• There is a type of error using #54
• Lack of defense against fd attacks, need a timeout error #54 #57
• Some users want to be able to support event stream output instead of callback，0.2 should support both programming modes at the same time #58
• Let user control turn protocol on and off, breaking change #62
• May need to support each protocol has their own codec, and does not require the same structure(trait object) #63
• Add poll API to all protocol handle, to allow users to customize some stream tasks in the handle #65

release 0.2.0-alpha.1

• Abstract transport layer #76
• Maybe there are other problems, let us wait and see in the evolution process.

• Verify remote pubkey
• Expose PeerId to upper protocols

add gossip message routing protocol on new p2p backend. Task issue.

Hi, I'm trying to use the tokio-yamux in my project, but i have encountered a problem.

in the example i can find the codes below

tokio::spawn(async move {
            loop {
                match session.next().await {
                    Some(_) => (),
                    None => break,
                }
            }
        });

I know this is like an engine for client to send the message out. but this session is moved to the async block, and we can not use it anymore. so all the streams of this session should be opened before spawn the async block.

but in my senario, the yamux client is a proxy, the stream is opened based on the new connection coming to the proxy, so I can not open all streams before spawn the async block. I tried to workaround by calling other methods in session to make sure the events of client be sent out. but i found that only calling next() can the client send events out.

So is there any way to solve my issue?

thanks very much

Hi, I'm using tokio-yamux in my project, and this tokio-yamux helps me a lot, thanks for this excellent lib.

I have encountered a problem.

I opened some streams, and copy the io from my served connections to those stream and also from those streams to my served connections.
I have tested an exceptional use case that when I close the server side of yamux, I expect that the copying threads should stop. but the reality is that it is still running.

So my question is: How to stop the Read or Write of the yamux stream, when the underlying connection is closed.
I tried to add control.close() in the "next call thread" but it is still no use.

tokio::spawn(async move {
                loop {
                    match agent_session.next().await {
                        Some(_) => (),
                        None => {
                            debug!("closing session");
                            health_control.close().await;
                            break;
                        }
                    }
                }
            });

Is it something I ignored? or are there any other suggestion for this use case?

Runtime compatible

• yamux timer (#268 )
• tentacle timer and spawn(#269 )

Browser compatible

• websocket abstract encapsulation(#274 )

Cryptographic algorithms compatible

Essential

• Secp256k1(#273 )
• Other hash algorithms, such as sha256 etc..(#273 )
• Hmac Sha256/Sha512(#273 )

Optional priority support for one of the major categories

• ECDH private key negotiation
• • EcdhP256
• • EcdhP384
• • X25519(maybe we should add support for this algorithm)(#273 #271 )
• AEAD symmetric encryption algorithm
• • Aes128Gcm
• • Aes256Gcm
• • ChaCha20Poly1305(#273 )