You can check the issues list - there are some easy issues if you want to deep into tox-rs development.
I hope above article to translate to Korean and post it Korean Devs community site with original’s link.
Can I?
but this means that we must have a point for DoS attack.
How should we handle this
unrecoverable error?
Nom5.0 has a concept of
unrecoverable error, it means that nom can’t continue parsing, so terminating process or thread is needed.
Why terminate process? We can clear our buffer and start parsing again when new data will come from the socket
When I try to run the example I get this:
[2019-06-12T07:42:27Z ERROR tox::toxcore::dht::server_ext] Failed to handle packet: HandlePacketError { ctx: HandleDataResponseError { ctx: HandleDhtPkAnnounceError { ctx: stack backtrace:
...
toxcore/onion/client/mod.rs:515
...
Invalid no_reply }
Failed to handle DHT PublicKey announce }
Handling OnionClient packet failed }Is this normal?
We should hide errors -> info, because they may make users nervous =)
I am not sure why, but now I get
Processing ended with error: Custom { kind: Other, error: Compat { error: EncodeError { ctx: Os { code: 65, kind: Other, message: "No route to host" }the only part in the stacktrace that hints to tox is:
11: <tox::toxcore::dht::codec::EncodeError as core::convert::From<std::io::error::Error>>::from::h5f8353515d42ff73 (0x1053cdd2f)
at /Users/inosms/Desktop/tox/src/toxcore/dht/codec.rs:104any hints?
You can try to play with bootstrap nodes list.
Perhaps some of them are not available from your network...
We have a sink for friend requests inside onion_client: https://github.com/tox-rs/tox/blob/a971a93ba33c09accf2ad1a06a023e684d0b49b1/src/toxcore/onion/client/mod.rs#L312
We should add a setter method for it and like for other sinks.
But we can receive friend requests not only from onion client.
It can be received as lossless packet from net_crypto.
I'm not sure in which cases friend request can be sent via net crypto but c-toxcore has a handler for it.
But that would mean we need to pass lossless packets via friends module as well (which we might need anyway) - right now we don't.
I think for a start it'll be enough to handle friend requests directly from onion client and later we can refactor it.
#[derive(Debug, Clone, PartialEq)]
pub enum Err<E> {
Incomplete(Needed),
Error(E),
Failure(E),
}
I worry that the Generic Err may increase code complexity.
Right?
#[derive(Clone, Debug, PartialEq, Fail)]
pub enum GetPayloadErrorKind {
/// Error indicates that received payload of encrypted packet can't be decrypted
#[fail(display = "Decrypt payload error")]
Decrypt,
/// Error indicates that decrypted payload of packet can't be parsed
#[fail(display = "Deserialize payload error: {:?}, data: {:?}", error, payload)]
Deserialize {
/// Parsing error
error: nom::Err<(&[u8], ErrorKind)>,
/// Received payload of packet
payload: Vec<u8>,
}
}error[E0106]: missing lifetime specifier
--> src/toxcore/dht/packet/errors.rs:64:30
|
64 | error: Box<nom::Err<(&[u8], ErrorKind)>>,
| ^ expected lifetime parameterFail requires static but can’t give static.
If i give it static then
error[E0597]: `decrypted` does not live long enough
--> src/toxcore/dht/packet/ping_request.rs:93:46
|
93 | match PingRequestPayload::from_bytes(&decrypted) {
| -------------------------------^^^^^^^^^^-
| | |
| | borrowed value does not live long enough
| argument requires that `decrypted` is borrowed for `'static`
…
You can store &str (or any reference) in a struct without a lifetime specifier
Thanks!