The server should bind to all addresses

[quixoticaxis]

Hello.

I was playing around with multiple servers inside a single process and found out a strange behavior: the server binds only to one IP address. For example, with_host("localhost").with_port(7878) used to run two servers in separate threads manages to start two instances of the server on my machine, one server is bound to IPv4 127.0.0.1, while the other is bound to IPv6 ::1. Is it intended?
Coming from .Net where Kestrel (ASP.Net web server) is binding to all addresses, I find the current behavior non-intuitive and wonder how the end-user of Trillium may handle it.

[jbr]

Is this intended? Yes, until there's a clear use case to justify the complexity, since I couldn't think of a real-world production use case for binding multiple ports.

What's the use case in which you'd need to bind multiple hosts or ports? Explain to me why you need that?

[quixoticaxis]

There is also scenario of handling multiple network adapters.

[jbr]

Multiple host+port combinations, understood. It would be identical to binding multiple ports due to how rust does tcp binding, but in this case the ports would be the same. One possibility with the current code (using async-std as an example) would be

use async_std::prelude::*;
fn main() {
    async_std::task::block_on(run_app("127.0.0.1").race(run_app("::1")));
}

async fn run_app(host: &str) {
    trillium_async_std::config()
        .with_host(host)
        .run_async((Logger::new(), |conn: trillium::Conn| async move { conn.ok("example") }))
        .await
}

If you need to share state across those applications, it would be slightly more involved, but supporting this uncommon use-case is possible currently. The question is whether it's common enough to incorporate into the runtime adapters.

[quixoticaxis]

Ah, I see, merging two state machines to effectively run two servers under the hood.

I believe serving both IPv4 and IPv6 is a pretty common scenario, that's why I mentioned this is the behavior of Kestrel. Multiple network adapters are probably niche.

[jbr]

Yeah, even if we implemented this in the runtime adapters, it would still be running one TcpListener for each SocketAddr and merging the streams. This doesn't exactly merge the streams, but I would be surprised if there was any meaningful performance difference. The primary advantage of implementing it directly in the runtime adapter is that they call Handler::init before wrapping the handler in an Arc, and that logic would need to be handled outside the runtime adapter in order to share state across the different TcpListeners.

[quixoticaxis]

A quick search showed that it seems that TcpListener has undocumented functionality of dual stack binding, and the behavior is platform specific.
Well, looks like it's too much hustle to implement. The discussion about Warp also has the idea of simply running two state machines.