Rust: 记录一下 debug

问题: 5.2多线程版本的评论 https://github.com/sunface/rust-course/discussions/1157#discussioncomment-5497000

为啥那段程序 TcpStream 中会接收到 empty string 导致 unwrap panic 复现代码:

client:

let mut socket = TcpStream::connect("127.0.0.1:7878").await?;
    socket.shutdown().await?;
    Ok(())

server:

fn main() {
    let listener = TcpListener::bind("127.0.0.1:7878").unwrap();

    for stream in listener.incoming() {
        let stream = stream.unwrap();
        handle_connection(stream);
    }
}

fn handle_connection(mut stream: TcpStream) {
    let buf_reader = BufReader::new(&mut stream);

    let request_line = buf_reader.lines().next().unwrap().unwrap();

    let (status_line, filename) = match &request_line[..] {
        "GET / HTTP/1.1" => ("HTTP/1.1 200 OK", "hello.html"),
        "GET /sleep HTTP/1.1" => {
            thread::sleep(Duration::from_secs(5));
            ("HTTP/1.1 200 OK", "hello.html")
        }
        _ => ("HTTP/1.1 404 NOT FOUND", "404.html"),
    };
    let contents = fs::read_to_string(filename).unwrap();
    let length = contents.len();
    let response = format!("{status_line}\r\nContent-Length: {length}\r\n\r\n{contents}");
    stream.write_all(response.as_bytes()).unwrap();
}

这里的原因很可能是由于我上面写的那样, client shutdown 了 socket, 然后服务端 recv 空的字符串 ^1 至于为啥会过一段时间会 panic, 我猜测和浏览器的 tcp socket 状态改变有点关系, 不过不是重点我就忽略了, 后面有知道了我再补充

更为细致的探索

首先掏出祖传 TCP state machine
然后再掏出 sudo tcpdump -nS -ttt port 7878 -i all 和 nc 127.0.0.1 7878 看一下连接情况, 这时候再找找 rust 怎么处理 FIN (close) 的 ^2
根据代码

impl<B: BufRead> Iterator for Lines<B>
// ...
match self.buf.read_line(&mut buf) {
            Ok(0) => None,
// ...

和另一则社区回答^3 知道了标准处理 close 的办法就是看读取到的 buf 是否为 0 (原谅我一直在做应用层, 不太清楚这里的弯弯绕绕 😭)

bxb100 / bxb100.github.io

Rust: 记录一下 debug #37

更为细致的探索