resource leak maybe exist in websocket

[zylthinking]

I found that: after I drop the websocket (I even close it manully to make sure), the system socket may still exist with state ESTABLISHED;

I have logs to ensure the socket has been closed at application level. Like below:

async fn handle_socket(mut socket: WebSocket, pool: pool::Pool) {
    use tokio::time::{self, *};

    let mut link = links::Link::new();
    let nr = links::ONLINE.fetch_add(1, Ordering::Relaxed);
    info!("connection +1, total: {}", nr + 1);

    let mut n1 = 0;
    let mut n2 = 0;
    let mut intv = time::interval_at(Instant::now(), Duration::from_secs(10));
    loop {
        tokio::select! {
            r = socket.recv() => {
                let Some(msg) = r else {
                    info!("connecion will break because of: {r:?}");
                    _ = socket.close().await.map_err(|e| error!("socket close failed {e}"));
                    break
                };
                n2 = 0;

                match msg {
                    Ok(Message::Ping(data)) => {
                        _ = socket.send(Message::Pong(data)).await;
                    }
                    Ok(Message::Binary(bin)) => {
                        if let Some(resp) = link.handle_pb_req(&pool, bin).await {
                            _ = socket.send(Message::Binary(resp.m2b())).await;
                        }
                    }
                    _ => {}
                }
            }

            bin = &mut link => {
                _ = socket.send(Message::Binary(bin)).await;
            }

            _ = intv.tick() => {
                link.tick(n1).await;
                n1 += 1;
                n2 += 1;
                if n2 == 6 {
                    warn!("connection will break because of heart beat");
                    _ = socket.close().await.map_err(|e|
                        error!("socket close failed {e}")
                    );
                    break;
                }
            }
        }
    }
    link.tick(-1).await;

    let nr = links::ONLINE.fetch_sub(1, Ordering::Relaxed);
    info!("connection -1, total: {}", nr - 1);
}

After the logs says no connection left, netstat still shows there are established connections.

I also noticed there are 2 system socket for one websocket, is this necessary?

[finnbear]

Have you verified that the close future finishes? Note that the WebSocket close handshake must succeed or fail before the TCP connection can be closed. Perhaps you should add a timeout to ensure close doesn't take too long. An easy way is to use tokio::time::timeout.

[zylthinking]

Have you verified that the close future finishes? Note that the WebSocket close handshake must succeed or fail before the TCP connection can be closed. Perhaps you should add a timeout to ensure close doesn't take too long. An easy way is to use tokio::time::timeout.

Sorry I can't understand, isn't

socket.close().await.map_err(|e|
    error!("socket close failed {e}")
);

enough?

To my understanding, close().await will make sure the close finished (successfully or not), and that was the last thing I did with the web socket -- I didn't close tcp socket, because I believe the dropping the web socket will do that.

I just assure dropping the websocket will release all resouce, and to be honest, what can I do except logging && ignoring the potential failure of socket.close().await?

By the way, the log 'socket close failed {e}' did not appear in my logs

[zylthinking]

Have you verified that the close future finishes? Note that the WebSocket close handshake must succeed or fail before the TCP connection can be closed. Perhaps you should add a timeout to ensure close doesn't take too long. An easy way is to use tokio::time::timeout.

Are you saying socket.close().await never returned, so I should abort the close and just continue to drop the web socket?
While, I didn't call the close manually until I noticed the tcp socket kept open when the web socket got dropped.

That means, dropping the websocket without close or close().await before dropping both caused the leaking, so, a time out just skip from my new behavior to old behavior, it can't change anything