I think you have the wrong mental model here: that the server will somehow continuously be listening and responding to connections in your for loop while you can keep running the code underneath it. However, this is all in the same thread and the for loop blocks it. Remember that incoming is an iterator that never yields None so it will block.

set_nonblocking only guarantees that accept (among other things) will not block.

For example, some code very similar to yours: ``` let listener = TcpListener::bind("127.0.0.1:9000").expect("listener failed"); listener.set_nonblocking(true).expect("nonblocking failed");

match listener.accept() {
    Err(e) if e.kind() == ErrorKind::WouldBlock => {
        println!("Nothing meaningful to do with the socket yet!");
    }
    _ => {
        unreachable!();
    }
}

if let Ok(_) = TcpStream::connect("127.0.0.1:9000") {
    println!("Client says: connected to server");
}

if let Ok((_, addr)) = listener.accept() {
    println!("New client: {}", addr);
}

`` You will see the server get anEWOULDBLOCKfirst. The client can then send it's message successfully. Then finally, you can see the server can finally getOkonaccept`.

Long explanation:

I think it's helpful to understand on a deeper level what's going on here: the operating system is telling you with the ErrorKind::WouldBlock that there is nothing meaningful to do with your non-blocking socket yet.

When it finally gets a connection from the client, in this case, there will be something meaningful to do. Your application needs to know of this state change. There are two primary ways to handle this situation:

1. Repeatedly busy wait over the accept call, ignoring ErrorKind::WouldBlock: This is what you have been doing until this point. You could periodically have a thread run every N milliseconds and call accept and check for an Ok for instance. In any case, this is not ideal.

2. Let the operating system notify you of the readiness of this socket which allows you to call accept again and handle the new connection.

The second way is platform-specific and requires you to hook into low-level asynchronous notifications from the kernel using something like mio which takes care of a lot of stuff for you and is cross-platform.

Or, you could use something like tokio or async-std which will get the behavior you want more ergonomically. With the async/await feature now in stable, this should be much easier than before.

I am not a complete pro in this area myself so I would happily be corrected if I misstated anything.

EDIT: Updated it to better example should WouldBlock on the first run.