addr::remote filter doesn't work with Server::run_incoming

[tedsta]

Hi! I have a (perhaps ugly / misguided) use-case where I need to get at the underlying file descriptor of each incoming WebSocket so that I can pass it to libc to get the linux-specific send-q stat - how much unacknowledged data is in the queue.

A solution to my use-case is to store the file descriptor of each incoming socket in a HashMap<SocketAddr, RawFd> using TryStreamExt::inspect_ok. This works as long as one can get the SocketAddr of the connection from inside the warp filters.

Unfortunately that's not currently possible, because run_incoming wraps everything in LiftIo, which always returns None for Transport::remote_addr().

A solution to this is to expose Transport and run_incoming2 (probably under a new name) so that people can implement Transport for their own types and pass it directly to run_incoming2.

[jxs]

Hi, have you seen the filter to service conversion?
also see #16 (comment), make_service_fn receives AddrStream which implements Transport

[tedsta]

Oh cool! That almost works for me, but AddrStream does not implement AsRawFd. The underlying tokio::net::TcpStream does, but AddrStream doesn't provide any way to get at it with a borrowed &AddrStream (and no way to convert a tokio::net::TcpStream back into an AddrStream even if it were owned). I think that solves my use-case as far as warp is concerned though, I'll have to take the AsRawFd issue to hyper. Thanks.

I still feel that it is a bit of a wart that there is no way to make warp::addr::remote() work in a situation where it is technically possible.