Rust rpc error in on projectile attack

I have some more information. This appears to be a MacOS/SecureTransport error. I can’t find where that string «connection closed via error» is actually built but it matches the comment for error -9806. I tested on Linux just now and the behavior is different: the server’s RpcSystem does finish cleanly for each connection.

So maybe something on the client-side isn’t shutting down the connection cleanly? Does capnp-rpc-rust call AsyncWrite’s shutdown method on the client side? I think that’s where a TLS stream is supposed to have an opportunity to clean up.

I was thinking along the lines of (1). The documentation mentions that input_stream and output_stream have to be «futures-enabled» but the signature doesn’t reflect that. However, I was trying to figure out where shutdown would be called from and I couldn’t quite get it; since the output_stream is just passed into a write_queue how is it supposed to know when it’s «done»? I see the terminate method on Sender but don’t know how to get from there to the write_queue‘s output_stream.

I’m working on the approach of changing std::io:Write to tokio_io::AsyncWrite and then calling AsyncWrite::shutdown appropriately. Changing the signatures is straightforward (I didn’t get any complaints from examples or tests after the change). However, I haven’t figured out yet when to call shutdown. What’s the correct way of cleanly shutting down the client’s RpcSystem now? I was just letting everything drop in my example but it seems like there should be some way to let the RpcSystem know that I’m done with it before dropping.

Yes, I think that’s correct and it’s the first thing I tried (well, I just put a couple printlns in where I thought shutdown would be invoked) but my example never gets to that point. After the request runs everything is just dropped and the RpcSystem isn’t polled to completion. That’s why I thought there would have to be something done to the RpcSystem to let it know that I was done with it. Does my question about cleanly shutting down the RpcSystem make sense now? Because I’ve already handed the instance off to handle.spawn I can’t just call a method on it any more so I think I’d have pass in some optional ‘shutdown notifier’ when constructed. I don’t really want to complicate the API because I like how it works now; I’m trying to find the minimum I can do to end up calling shutdown in the correct place just to see if that fixes the issue. I was also thinking it could call shutdown somehow depending on what state it was in when dropped but someone on the tokio gitter suggested that was a bad thing to try and do IO in the drop method. I’ll work on this some more over the weekend.

struct Wrapper<W> where W: AsyncWrite {
   writer: Option<W>,
   send_on_drop: futures::unsync::oneshot::Sender<W>,
}

impl <W> AsyncWrite for Wrapper<W> where W: AsyncWrite { ... }

impl <W> Drop for Wrapper<W> {
   fn drop(&mut self) {
     if let Wrapper { writer: Some(mut w), send_on_drop: Some(mut s), } = *self {
        s.send(w);
     } else {
      unreachable!()
    }
   }
}

impl RpcSystem {
    fn get_disconnector(&self) -> Disconnector { ... }
}

I went the Disconnector route and that works well, better than expected even: the connection no longer errors out on the server side even though I didn’t call the AsyncWrite::shutdown method! I’m guessing that’s because the capnp ‘abort’ message triggers the server to close the connection instead but I haven’t dug into that yet. The only thing I had to do that was unexpected was to make sure the tokio core event loop turned again after the disconnect. I think that’s to get the last write out the door and maybe get the disconnect_fulfiller to run. I was thinking that I’d make Disconnector a future and then my poll wouldn’t return ready until *connection_state.borrow() matched None.

What do you think about calling shutdown in light of the new disconnect behavior? I feel like it’s still the right/clean thing to do but since it isn’t actually a problem now I’m inclined to leave the signatures as Write.