Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 19 2021 08:26
    coveralls commented #461
  • Nov 19 2021 08:17
    kurnevsky synchronize #461
  • Nov 19 2021 08:17

    kurnevsky on dht_state

    refactor(dht): introduce a sing… (compare)

  • Nov 13 2021 13:08
    kurnevsky commented #459
  • Nov 13 2021 12:44
    kpp commented #459
  • Nov 13 2021 08:17
    coveralls commented #461
  • Nov 13 2021 08:10
    kurnevsky opened #461
  • Nov 13 2021 08:10

    kurnevsky on dht_state

    refactor(dht): introduce a sing… (compare)

  • Nov 13 2021 06:40

    kurnevsky on rust2021

    (compare)

  • Nov 13 2021 06:40
    kurnevsky closed #460
  • Nov 13 2021 06:40

    kurnevsky on master

    chore(rust): use 2021 edition Merge pull request #460 from to… (compare)

  • Nov 13 2021 05:08

    suhr on rustfmt

    (compare)

  • Nov 12 2021 21:08
    kurnevsky synchronize #460
  • Nov 12 2021 21:08

    kurnevsky on rust2021

    chore(rust): use 2021 edition (compare)

  • Nov 12 2021 21:00
    kurnevsky synchronize #460
  • Nov 12 2021 21:00

    kurnevsky on rust2021

    chore(rust): use 2021 edition (compare)

  • Nov 12 2021 20:53
    kurnevsky opened #460
  • Nov 12 2021 20:53

    kurnevsky on rust2021

    chore(rust): use 2021 edition (compare)

  • Nov 12 2021 20:50

    kurnevsky on nom

    (compare)

  • Nov 12 2021 20:49
    kurnevsky closed #266
Evgeny Kurnevsky
@kurnevsky
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.
Evgeny Kurnevsky
@kurnevsky
So probably we should merge friend requests streams inside friends module.
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.
inosms
@inosms
ok thanks for the hints!!!
Cho
@NamsooCho
Create one unified DecodeError::Deserialize variant and place there nom::Err rather than placing Incomplete and Error separately.
#[derive(Debug, Clone, PartialEq)]
pub enum Err<E> {
  Incomplete(Needed),
  Error(E),
  Failure(E),
}
I worry that the Generic Err may increase code complexity.
Roman
@kpp
How many generic E in nom code?
Cho
@NamsooCho
I found solution. Use it by E as (&[u8], nom::error::ErrorKind)
Right?
Cho
@NamsooCho
#[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 parameter
Fail 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`
…
Roman
@kpp
That's right
You can store &str (or any reference) in a struct without a lifetime specifier
Cho
@NamsooCho
Ah
Thanks!
Roman
@kpp
So you have to either use String or another type
Cho
@NamsooCho
Ah I got it
inosms
@inosms
uh thanks for merging! :confetti_ball:
Cho
@NamsooCho
I will use &Vec<u8>, it also uses heap
Roman
@kpp
You can't store & in a struct
Cho
@NamsooCho
Then Vec<u8> can be used.
It is sized.
Cho
@NamsooCho
Is String better?
I thought Vec<u8> is lighter than String because of UTF-8.
Roman
@kpp
Not Vec<u8>, because you can't display it, so String is better
inosms
@inosms
A short question: Is there some way I can use tox-rs as multi-purpose p2p communication library? For example can I use the TCP connection to send arbitrary data?
Evgeny Kurnevsky
@kurnevsky
Not right now, but we are close. You can use net crypto connection to send custom packets to friends. Right now it works with udp and recently I managed to make tcp part work as well (only locally, there are still bugs and not yet done things). Also we don't have pleasant api for it yet - it looks like echo server example you recently saw which is too complex right now.
inosms
@inosms
Sounds really good though! What kind of API are you imagining? Maybe I can help a bit with that!
Evgeny Kurnevsky
@kurnevsky
I think about high level wrapper for all this onion-net_crypto-friends machinery. Something like this: https://github.com/TokTok/c-toxcore/blob/master/toxcore/tox.h
inosms
@inosms
I see, this might be too big of a task for me as I am just starting to grasp the whole project...
Roman
@kpp

branch file_sending:

error[E0495]: cannot infer an appropriate lifetime for autoref due to conflicting requirements
   --> examples/echo.rs:169:31
    |
169 |                 Box::new(fs_c.send_file_control(pk, packet.file_id, TransferDirection::Receive, ControlType::Accept)
    |                               ^^^^^^^^^^^^^^^^^
    |

Any idea how to fix it?

@kurnevsky ?
Evgeny Kurnevsky
@kurnevsky
It's because of the signature of send_file_control.
    pub fn send_file_control(&self, friend_pk: PublicKey, file_id: u8, dir: TransferDirection, control: ControlType)
                             -> impl Future<Item=(), Error=SendPacketError> + Send + '_ {
Roman
@kpp
+ '_ is required?
Cho
@NamsooCho
Yes. It is required to compile.
Evgeny Kurnevsky
@kurnevsky
It requires &self to live as long as future.
@NamsooCho do you really need all these futures inside send_file_control?
It seems get_friend can return plain value.
Then I see a lot of and_thens that also don't need to be futures...
It seems the only real future is send_file_control_packet?