Right now it only connect to remote servers, but does not allow remote servers to connect to self.

Probably due to duplicate calls of Disconnected or missing calls of Connected.

Right now everything is just println!.

Note that when poll returns NotReady, future would then require a "notifier" to wake up and poll again. This might not be aligned with the current implementation and caused the random stop issue.

Properly deal with tokio's event-loop system both in DPT and RLPx to make it more responsive.

Consider when RLPxStream's poll is in NotReady state. At this time, if a new PingTimeout is being sent, and all the connection is lost, poll will never be called and active_peers will not be removed.

Instead of retry on Disconnect message, which could still result in less and less peers over time.

This is required for Status message to work.

Node might not be on the same side as the client, in this case it needs this message.

etcommon_bigint latest version 0.1.15 remove etcommon_bigint::LogsBloom, so in eth/proto.rs there is a compile error .

remove LogsBloom in proto.rs in use, compile is ok

Right now it hits a dead end and silently fails.

why there is no tcp listenning for others connectting

https://github.com/rust-ethereum/devp2p/blob/f00664fa84d14d217ed895ec6300f6b6b87c2937/src/ecies/proto.rs#L121

This is incorrect and causing issues in practice. The reason is returning Ok(None) tells the codec that it needs to read more bytes from the network, however it could have already read and buffered the body following the header, meaning it will just block on the socket waiting for more data which might not be coming before decoding the complete body that might already be sitting in the buffer.

https://docs.rs/tokio-util/0.5.1/tokio_util/codec/trait.Decoder.html

"If the bytes look valid, but a frame isn't fully available yet, then Ok(None) is returned. This indicates to the Framed instance that it needs to read some more bytes before calling this method again.

Note that the bytes provided may be empty. If a previous call to decode consumed all the bytes in the buffer then decode will be called again until it returns Ok(None), indicating that more bytes need to be read."

Additionally you can see in the implementation if Ok(None) is returned then the state will be toggled to not readable:

https://github.com/tokio-rs/tokio/blob/647299866a2262c8a1183adad73673e5803293ed/tokio-util/src/codec/framed_impl.rs#L144

I realize the point is to forward the state to ECIESState::Body but it can't be done like this, as decode() will not be called again after returning Ok(None). Two obvious alternatives are something like recursing into another call of decode(), or returning some kind of Item that gets ignored on the upper layer, but the first is probably the easiest (replacing Ok(None) with self.decode(buf))

We currently use C binding rust-secp256k1. Consider also support libsecp256k1!