RTMP: 断流重连需要等待几秒

[greenhatking999]

描述(Description) 使用obs推流测试，客户端主动断开推流，然后重新推流无法建立连接，大约4-5秒后恢复

1. SRS版本(Version): srs-4.0.139
2. SRS的日志如下(Log): [2021-07-13 17:14:47.392][Trace][17398][252257sn] TCP: before dispose resource(RtmpConn)(0x14cb230), conns=3, zombies=0, ign=0, inz= 0, ind=0 [2021-07-13 17:14:47.392][Error][17398][252257sn][11] serve error code=1028 : service cycle : rtmp: stream service : rtmp: stream /live/test is busy
3. SRS的配置如下(Config): 默认配置

重现Bug的步骤(How to replay bug?)

1. 点击断开开始推流，然后点击停止推流。再点击开是推流，需要等待4-5秒才能推流成功

期望行为(Expect)

期望断开连接后，能够瞬间连接srs成功。 在一些网络不稳定的情况下，客户端断开推流是非常常见的。而客户端都有断开重连机制，如果这4-5秒时间能够节省下来，用户端观看直播可能会顺畅很多。

[winlinvip]

No wonder my republished testcase would fail.

TRANS_BY_GPT3

[xiaozhihong]

Unable to reproduce, is the default configuration conf/srs.conf?

TRANS_BY_GPT3

[xiaozhihong]

obs parameter configuration screenshot, and also the complete SRS log, please send them all.

TRANS_BY_GPT3

[terry8204]

Have you guys solved this issue? 3.0-r2 [2021-08-23 16:37:58.433][Error][30260][27979][11] serve error code=1028 : service cycle : rtmp: stream service : rtmp: stream /live/13800138000_1_0_1078_video is busy [2021-08-23 16:37:58.936][Trace][30260][27981] client identified, type=flash-publish, vhost=video.gps51.com, app=live, stream=13800138000_1_0_1078_video, param=, duration=0ms [2021-08-23 16:37:58.936][Trace][30260][27981] connected stream, tcUrl=rtmp://video.gps51.com:1935/live, pageUrl=, swfUrl=, schema=rtmp, vhost=defaultVhost, port=1935, app=live, stream=13800138000_1_0_1078_video, param=, args=null [2021-08-23 16:37:58.936][Trace][30260][27981] source url=/live/13800138000_1_0_1078_video, ip=61.141.72.211, cache=1, is_edge=0, source_id=27585/27186 [2021-08-23 16:37:58.936][Error][30260][27981][11] serve error code=1028 : service cycle : rtmp: stream service : rtmp: stream /live/13800138000_1_0_1078_video is busy

TRANS_BY_GPT3

[terry8204]

My problem has been resolved. It was caused by multiple threads during streaming, where the failure to close the socket when ending the previous thread.

Problem reproduction:

1. Start streaming.
2. Click on play to start playback.
3. Keep the video playing and disconnect the streaming.
4. Try to start streaming again, but it fails and displays the error message "is busy".

TRANS_BY_GPT3

[winlinvip]

I'll see if I can reproduce it.

TRANS_BY_GPT3

[duiniuluantanqin]

My problem has been resolved. It was caused by multiple threads during streaming, where the socket was not closed when ending the previous thread.

Problem reproduction:

1. Push stream
2. Click to play
3. Keep the video playing, disconnect the push stream
4. Push stream, fail, prompt "is busy

Couldn't reproduce it. Can you explain how you solved it?

TRANS_BY_GPT3

[HowQuitVim]

Steps to reproduce:

1. Set the default value of normal_timeout in the configuration file to 5 seconds.
2. During the streaming process, abruptly disconnect (e.g., by turning off the WiFi on a mobile phone or unplugging the Ethernet cable on a computer).
3. Within 5 seconds, reconnect the mobile phone to WiFi and attempt to stream to the same URL.

Cause analysis: The streaming client abruptly disconnected the TCP connection, but SRS cannot immediately detect that the client is offline. It needs to wait for 5 seconds (normal_timeout) to detect that the streaming client is offline. During these 5 seconds, SRS considers the connection to be normal. If the client's network is restored and it starts streaming again within these 5 seconds, SRS will consider that there is another streaming client with the same URL, resulting in a "busy" error. It is easier to reproduce this issue by setting a larger value for normal_timeout.

TRANS_BY_GPT3

[peipeiguo]

Is 5 seconds too long as the default? Should we reduce normal_timeout a bit so that the reconnection and re-push can quickly recover?

TRANS_BY_GPT3

[winlinvip]

Abnormal disconnection cannot be detected, this is a characteristic of TCP, and it is unsolvable.

TRANS_BY_GPT3