The player repeatedly requests a non-existent http-flv stream, resulting in a large number of close_wait connections, which will be included in the clients statistics.

[rageJune]

Player repeatedly requests non-existent http-flv streams, repeatedly pulls and disconnects, close_wait will increase, and will be included in the statistics of clients.

srs version: 3.0.45
Configuration file: conf/http.flv.live.conf

Originally posted by @rageJune in #858 (comment)

TRANS_BY_GPT3

[rageJune]

Also tested the situation in cluster mode:

## edge.conf
listen              1935;
max_connections     1000;
pid                 objs/edge.pid;
daemon              off;
srs_log_tank        console;
http_api {
    enabled         on;
    listen          1985;
}
http_server {
    enabled         on;
    listen          8080;
    dir             ./objs/nginx/html;
}
vhost __defaultVhost__ {
    cluster {
        mode            remote;
        origin          127.0.0.1:19350;
    }
    http_remux {
        enabled     on;
        mount       [app]/[stream].flv;
        hstrs       on;
    }
}

After pulling a non-existent FLV stream and disconnecting, the connection between origin and edge is still being repeatedly established.

TRANS_BY_GPT3

[rageJune]

After carefully reviewing the solution and code in #636, it seems that the final issue is that the error was not passed to "trd" after receiving the client close signal SrsHttpConn::pop_message(&req).

`srs_error_t SrsHttpRecvThread::cycle()
{
srs_error_t err = srs_success;

while ((err = trd->pull()) == srs_success) {
    ISrsHttpMessage* req = NULL;
    SrsAutoFree(ISrsHttpMessage, req);
    
    if ((err = conn->pop_message(&req)) != srs_success) {

trd->interrupt(); // Modify the state of "trd" here, and then it will be able to exit "do_serve_http" in srs_app_http_stream.cpp.
return srs_error_wrap(err, "pop message");
}
}

return err;

}`

TRANS_BY_GPT3

[winlinvip]

Use the command curl http://127.0.0.1:8080/live/livestream.flv -v -o /dev/null to read HTTP FLV.

Use the command sudo netstat -anp|grep -v LISTEN|grep srs to check for any FD leaks.

SRS2 Origin

I tested it, version 2.0.263, in origin mode, and there were no issues.

listen              1935;
max_connections     1000;
daemon              off;
srs_log_tank        console;
http_server {
    enabled         on;
    listen          8080;
}
vhost __defaultVhost__ {
    http_remux {
        enabled     on;
        mount       [vhost]/[app]/[stream].flv;
    }
}

SRS2 Edge

I tested the edge server of SRS2, and there were no issues.

listen              1935;
max_connections     1000;
daemon              off;
srs_log_tank        console;
http_server {
    enabled         on;
    listen          8080;
}
vhost __defaultVhost__ {
    mode            remote;
    origin          127.0.0.1:19350;
    http_remux {
        enabled     on;
        mount       [vhost]/[app]/[stream].flv;
    }
}

SRS3 Origin

I found a FD leak during testing, with the same configuration file.

[root@c81da0d70bf7 trunk]# sudo netstat -anp|grep -v LISTEN|grep srs
tcp6       0      0 127.0.0.1:8080          127.0.0.1:47106         CLOSE_WAIT  3939/./objs/srs    
[root@c81da0d70bf7 trunk]# lsof -p 3939
COMMAND  PID USER   FD      TYPE DEVICE SIZE/OFF       NODE NAME
srs     3939 root    9u     IPv6  50356      0t0        TCP localhost:webcache->localhost:47106 (CLOSE_WAIT)

SRS log:

[2019-04-06 07:47:54.737][Trace][3939][105] set fd=9, SO_SNDBUF=2626560=>175000, buffer=350ms

It is visible that this FD=9 is missing.

TRANS_BY_GPT3

[winlinvip]

Fixed by f2b4bc7