Open winlinvip opened 9 months ago
Right now, only SrsServer can receive the 'sigquit' message from the signal manager. RtcServer doesn't have this feature, so when we send SIGQUIT to SRS, only the services in srsServer can be stopped. The UDP servers in rtcServer don't stop. So, new webrtc stream requests for 'stun' still go to the old process.
TRANS_BY_GPT4
I guess SRT and GB haven't implemented this Graceful QUIT feature yet.
TRANS_BY_GPT4
It's not easy to implement Gracefully Quit in the UDP protocol because UDP doesn't have a state.
Also, the whole WebRTC system reuses UDP ports. Right now, it seems to be reusing FD, so it needs special handling.
As for SRT, its UDP is managed by the underlying library. To implement it, we might need to take a closer look at how the underlying system works.
TRANS_BY_GPT4
Just to add: You don't really need to worry about WebRTC's UDP. All you need to do is turn off the HTTP API, and it will be supported by default. This is because the main point of Gracefully Quit is to stop accepting new connections and then force an exit after a certain period of time.
SRT might be a bit more challenging because its new connections are also on UDP. Currently, GB only supports TCP, so you can just close the Listener.
TRANS_BY_GPT4
To gracefully shut down SRT, you just need to close the listener. If there are no current SRT connections, the UDP socket will be unbound. If there are, it will wait until all connections are gone before unbinding. During the UDP unbinding period, if a new connection comes in, the handshake packet will be received, but it will fail because the SRT listener has already been closed. If the client tries a few times, it might be able to send the request to a new server.
TRANS_BY_GPT4
void SrsServerAdapter::stop()
{
+ if (srs) {
+ srs->stop();
+ }
}
I have test this patch. TCP seems work well.
A relatively straightforward implementation would be that upon receiving a kill signal, both UDP and TCP cease to listen, and the program initiates an actual exit through another signal. The practical steps are as follows:
TRANS_BY_GPT4
This mechanism has issues that need to be examined when time permits. It would be even better if you could submit a pull request to resolve them.
TRANS_BY_GPT4
Description
Please description your issue here
Replay
Please describe how to replay the bug?
Step 1: Run SRS
Step 2: Publish a stream by FFmpeg
Step 3: Gracefully quit SRS
Expect
SRS should ideally wait for the RTMP connection to close or time out before quitting. However, it seems that SRS quits right away without waiting for the connection to close.
Solution
See https://gitee.com/ossrs/srs/pulls/2/files