Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Carl Lerche
    @carllerche
    hopefully next month is the answer
    there are some windows bugs
    reison1218
    @reison1218
    is there some one know where find mio's blog?
    Thomas de Zeeuw
    @Thomasdezeeuw
    @reison1218 Mio doesn't really have a blog, we've use Tokio's blog, e.g. the announcement of v0.7: https://tokio.rs/blog/2019-12-mio-v0.7-alpha.1/
    reison1218
    @reison1218
    @Thomasdezeeuw ok,thank u
    Harry Fei
    @harryfei
    Why do we use AsRawSocket instead of AsRawHandle on windows platform?
    RawSocket is just another RawHandle in miow
    IMHO, RawHandle is more generic.
    Thomas de Zeeuw
    @Thomasdezeeuw
    @harryfei We mostly follow the same API as std lib, it only provides AsRawSocket (see https://doc.rust-lang.org/std/net/struct.TcpStream.html). But you can open an issue if you think its worth it to the AsRawHandle API.
    Harry Fei
    @harryfei
    Gotcha, thanks
    matrixbot
    @matrixbot
    crentist hello guys, I'm trying to write a very simple chat system with mio, and i'm stuck on the broadcasting part
    crentist basically, when someone sends a message to the server, i'd like to broadcast it to every connected client (doesn't matter for now if i send it back to the sender)
    crentist i'm using most of the examples of the mio doc
    crentist but i have one big event loop, that checks tokens for given events, and i don't know how i could send a message to every client with the loop in a simple manner. Like once i get a "writable" for a given client i can send messages but that seems impractical
    crentist could any one point me in the right direction ?
    Thomas de Zeeuw
    @Thomasdezeeuw
    You could try writing the message to all clients and then put it into a pending buffer of some kind if the write call returns a WouldBlock error.
    matrixbot
    @matrixbot
    crentist thanks Thomas. I'm putting them in a VecDeque<Rc<&str>> for now.
    I have a different problem now. It seems like read calls won't work on the server side
    crentist i call socket.read(buf), and it reads 0 bytes, no matter what i try
    crentist quick n dirty, i'm doing this
    Thomas de Zeeuw
    @Thomasdezeeuw
    If you read 0 bytes the connection is closed (at least for writing) by the client
    It indicates no more bytes are coming
    matrixbot
    @matrixbot
    crentist i thought it would be, but i'm writing from the client and then waiting for a server response, so i don't see why the client would have closed this
    crentist it's blocked on the subsequent read, in the running client
    crentist to keep it short, client is in go and does this :
    c, := net.Dial("tcp", "localhost:12345")
    // omitted fro brievety...
    data,
    := json.Marshal(&m)
    c.Write(data)
    c.Read(data)
    crentist and blocks on the read line
    adamhass
    @adamhass
    @matrixbot You should wait for the channel to be readable again after reading 0 bytes, not closing it. And also make sure that there's space in the read_buf, I think I had a problem where the BufMut wasn't initialized and the read attempt always just returned 0.
    matrixbot
    @matrixbot
    crentist i tried with a Vec, so it should work, right ? I also tried initializing with a "vec![]" right before every read. Still no luck.
    I then tried just deleting the 'Ok(0)' branch of the match (so the connection is not closed server side), and it just does nothing...
    crentist like this, for my struct that has a socket and other info on a client
    crentist pub fn read(&mut self, buf: &mut Vec<u8>)-> io::Result<usize>{
    self.socket.read(buf)
    }
    adamhass
    @adamhass
    You should break the loop after reading 0 and wait for the Poll to return Readable again.
    matrixbot
    @matrixbot
    crentist aah thanks i'll that ! But then i should not use "read => 0" as a sign of disconnect ? I was thinking of using a ping thing, so more like a write
    adamhass
    @adamhass
    Yeah I'm not 100% sure but I believe the read returns an error if it's shut down remotely. You have to implement your own shut down message if you want to do it more gracefully.
    matrixbot
    @matrixbot
    crentist still no luck..
    crentist here's the full main
    crentist there are some wrappers but i don't think they're needed here, like this struct and methods
    crentist use crate::client_conn::ClientConn;
    adamhass
    @adamhass
    That vec looks empty
    Vec::with_capacity(100) instead of ::new()
    Thomas de Zeeuw
    @Thomasdezeeuw
    @adamhass good point. Reading into a Vec requires you to initialise it first. You can use something like buf.resize(2048, 0) before reading to fill it with zeros with a minimum length of 2kb.
    If that becomes a performance concern you'll need to use unsafe. But the io::Write trait should really have a method to reading a Vec<u8>.
    matrixbot
    @matrixbot
    crentist thanks a lot i'll try that
    Bruce
    @BruceBrown
    Mio Event question: Do I need to size the event capacity to be the same as the maximum connections I'll concurrently accept, or is the poll able to virtualize over a larger set of connections?
    Thomas de Zeeuw
    @Thomasdezeeuw
    @BruceBrown the capacity of Events only determines the maximum number of events you can receive from a single call to Poll::poll, it has no relation to the maximum number of connections you can handle.
    Depending on how often you call Poll::poll it doesn't have to be that large. I currently use 128, but rarely get more then ~10 events.
    Bruce
    @BruceBrown
    Thanks. That helps a lot. I'm also finding that poll exhausts its timeout and doesn't early return on an event. Or, am I mistaken and need to dig a bit deeper.
    Bruce
    @BruceBrown
    Did more digging, error on my part...