Possible to get access to peer's name?

[sholsapp]

I'm trying to find a way to get access to the peer's name (i.e., sockaddr_in equivalent) but this information doesn't seem to get propagated past the tokio-proto and tokio-io layers. Is this by design or just a missing feature? If this is by design, is the appropriate place to implement my idea (something that needs access to peer's name but also implementing a protocol/service) directly atop tokio-core?

Really, what I want is what is described in https://tokio.rs/docs/getting-started/pipeline-server/ examples, but with the socket and/or peer name passed through to the service.

[sholsapp]

P.s., let me know if this is wrong venue to ask this type of question, I'll gladly move it somewhere else. :)

[alexcrichton]

Ah yeah so currently this is difficult to do unfortunately.

The crate is generic over AsyncRead + AsyncWrite which means there's no easy access to, for example, remote_addr.

I think to handle this we'd need to add a new trait like trait RemoteAddr as well and bound by that, but that'd unfortunately leave out streams like SSL :(

[sholsapp]

Okay thanks @alexcrichton I just wanted to know if I was missing something obvious. I think that I can do what I want if I build starting at tokio-core layer, and then just duplicate some of the design that tokio-proto and tokio-io add, per the example.

I think to handle this we'd need to add a new trait like trait RemoteAddr as well and bound by that, but that'd unfortunately leave out streams like SSL :(

I don't follow and am curious... wouldn't an SSL stream still have a peer?

[carllerche]

I don't think duplicating any of -proto and -io is necessary. You can implement your ServerProto to take a type that knows the remote address, specifically TcpStream. You can then grab the address in bind_transport. On Thu, Apr 6, 2017 at 8:07 AM Stephen Holsapple [email protected] wrote:

Okay thanks @alexcrichton https://github.com/alexcrichton I just wanted to know if I was missing something obvious. I think that I can do what I want if I build starting at tokio-core layer, and then just duplicate some of the design that tokio-proto and tokio-io add, per the example.

I think to handle this we'd need to add a new trait like trait RemoteAddr as well and bound by that, but that'd unfortunately leave out streams like SSL :(

I don't follow and am curious... wouldn't an SSL stream still have a peer?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tokio-rs/tokio-minihttp/issues/20#issuecomment-292204306, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAYJISywjWAv6xMlrSJnkaT36a76Cvyks5rtP_OgaJpZM4M0l4h .

[alexcrichton]

@sholsapp oh sorry I just mean that one possible route for tokio-minihttp is to define a trait:

trait RemoteAddr {
    fn remote_addr(&self) -> SocketAddr;
}

and then require AsyncRead + AsyncWrite + RemoteAddr

Unfortunately though that trait wouldn't be easily implementable for types such as TlsStream<TcpStream>. It definitely has a possible implementation, it's just not automatic for you.