expose tokio::net::tcp_listener?

[yoshuawuyts]

In #11 we're adding an example of how to use this crate with the Hyper HTTP server. To get it to work, some glue is required:

  let args = Cli::from_args();
  let listener = args.port.bind()?;
  let handle = tokio::reactor::Handle::current();
  let listener = tokio::net::TcpListener::from_std(listener, &handle)?;

This seems like boilerplate that would probably be copy-pasted from between projects, which makes it seem like a prime candidate to create a method for.

I was thinking something like this:

  let args = Cli::from_args();
  let listener = args.port.bind_tokio()?;

The name here could probably use some work (cc/ @killercup, suggestions?) but I reckon the result would be really useful.

Setting up a complete HTTP server would then only require the following:

#[derive(Debug, StructOpt)]
struct Cli {
  #[structopt(flatten)]
  port: Port,
}

fn main() -> Result<(), Box<std::error::Error>> {
  let args = Cli::from_args();
  let listener = args.port.bind_tokio()?;

  let server = Server::builder(listener.incoming())
    .serve(|| service_fn_ok(|_| Response::new(Body::from("Hello World"))))
    .map_err(|e| eprintln!("server error: {}", e));

  tokio::run(server);
  Ok(())
}

Which I think is starting to become short enough that people can memorize it!

Drawbacks

This would add tokio as a dependency which adds a bit of overhead during compilation. But given that all major frameworks depend on it, it's probably safe to say it won't introduce any new dependencies for production systems.

[killercup]

Hm. Not sure I agree with this. I can see how this might come in handy, but I have two questions:

• How many crates will use hyper directly and would you also want to support other libraries?
• How many people would expect a crate called clap-port-flag to have tokio-specific code? (Similar to my comment in Feature: different loggers, --logger and --pretty clap-verbosity-flag#5, I wouldn't)

I think my main issue with this is that it is very specific to Hyper. If it were easier in hyper to use an existing socket, we wouldn't need this. In actix-web, e.g., you can pretty much to server.listen(args.port.bind()?) IIRC

[yoshuawuyts]

If it where easier in hyper to use an existing socket, we wouldn't need this.

Yeah I actually agree with this. Good point.

[yoshuawuyts]

Hmmm, on the other hand it would become harder to configure socket things like keepalive durations and the like. hyperium/hyper#1602 (comment)

edit: actually it looks like most options can be set on core's TcpStream struct. But tokio exposes more method, such as .set_recv_buffer_size(). This seems it should be mostly okay, and is the same recommendation actix-web has.

References

• https://docs.rs/hyper/0.12.6/hyper/server/conn/struct.Http.html#method.keep_alive
• https://tokio-rs.github.io/tokio-core/tokio_core/net/struct.TcpStream.html#method.set_recv_buffer_size

[yoshuawuyts]

Server::from_tcp() just landed in Hyper! hyperium/hyper#1624