tarpc icon indicating copy to clipboard operation
tarpc copied to clipboard

how to retrieve client connection information from within service

Open omac777 opened this issue 6 years ago • 3 comments

I was looking into the context structure passed within the service.

theContext:<<Context { deadline: SystemTime { tv_sec: 1557257164, tv_nsec: 0 }, trace_context: Context { trace_id: TraceId(2868105600740534249014), span_id: SpanId(8104557109609617082), parent_id: Some(SpanId(12301303019742098848)) } }>>

How does one retrieve the client connection information from within the service? i.e. remote ip address and port for the client we are currently serving i.e. Client IP: 192.168.0.99:54321 I did find .client_addr(), but it's not permitted to directly call this from self.client_addr() within the service handler: https://docs.rs/tarpc/0.17.0/tarpc/server/struct.Channel.html#method.client_addr

Which leads me to my next question? How do I use the self to get the Channel and following that the client address?

omac777 avatar May 07 '19 19:05 omac777

Rather than calling incoming.respond_with() do incoming.for_each(|channel| channel.respond_with()). That gives you a chance to take the peer addr from the channel. Something like this (modified README example):

#[derive(Clone)]
struct HelloServer(SocketAddr);
impl Service for HelloServer { ... }

...

    let server = Server::default()
        .incoming(transport)
        .map_ok(|channel| {
            let peer_addr = channel.get_ref().peer_addr().unwrap();
            let handler = channel.respond_with(service::serve(HelloServer(peer_addr)));
            tokio_executor::spawn(handler.unit_error().boxed().compat());
        })
        .for_each(|_| futures::future::ready(()));

...

tikue avatar May 12 '19 22:05 tikue

@omac777 was your question answered?

tikue avatar Jul 16 '19 02:07 tikue

Thank you for your reply.  I haven't had time to pursue this any further.  I placed other efforts looking into grpc stream like capabilities for very large file transfers minimizing memory usage on both client/server side while preserving long duration connections.

golang gupload uses grpc stream and had tls support out of the box.  Something similar to this in rust would have been ideal.

The pingcap rust grpc at first glance looked very interesting, but falls short when providing examples that are easy to follow and use.

Lastly, rust-provided tcpstream marshalled(encode/decode) each element but doesn't come with the out-of-box tls support and the async rusttls wasn't easily usable with this approach either.  It would be a nice change request to have tlstcpstream as a base rust type to facilitate this approach; it would feel more like golang if it did.  The other suggestion would to ensure all the connection info is accessible within the callback in order to filter out/disconnect from those undesirable clients. golang tls/grpc wins at the moment in terms of ease of use...up and running less than 5 minutes.  Months later still nothing equivalent in sophistication and ease of use in rust yet. On Monday, July 15, 2019, 10:45:34 p.m. EDT, Tim [email protected] wrote:

@omac777 was your question answered?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

omac777 avatar Jul 16 '19 11:07 omac777

I'm closing this ticket due to lack of activity, but if you are still interested in this, please feel free to reopen!

tikue avatar Feb 04 '24 08:02 tikue