ossrs / srs

SRS is a simple, high-efficiency, real-time video server supporting RTMP, WebRTC, HLS, HTTP-FLV, SRT, MPEG-DASH, and GB28181.

Home Page:https://ossrs.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

SOURCE: Possible race condition in SrsSource publish/unpublish

winlinvip opened this issue · comments

The publish and unpublish operations of SrsSource are not atomic, so when the Source becomes more complex, such as when there are thread switches, it may lead to race conditions.

TRANS_BY_GPT3

There is another consistency issue where some objects are expressed through construction and destruction, which means they do not support the restart method. These objects are relatively simple and do not require consideration of initial state or resetting of state. Examples of such objects are SrsProtocol and SrsStSocket. Objects that are constructed with a pointer are mostly not reusable.

Considering the possibility of reconnection, functions like restart or connect-close have been introduced for objects like SrsTcpClient and SrsSimpleRtmpClient. Is it necessary for these objects to be designed with the restart method? Is it necessary for them to have residual state, such as remembering the host and port for automatic reconnection? It seems that they do not.

Therefore, these APIs can be simplified to non-reusable objects. Only objects like SrsThread may require the restart method. Some resource management, such as file descriptors (fd), do not need to be reused after being closed, unless there is a very high frequency of restart, such as implementing automatic reconnection to a TCP server. However, this type of restart is closely related to the business logic.

Therefore, most objects can be considered not supporting restart. Although they have connect and close functions, these functions are only provided for convenience, where connect is called when needed after creating the object, and close does not necessarily need to support reconnection.

TRANS_BY_GPT3

timeout is sometimes in milliseconds (ms) and sometimes in microseconds (us), but currently it seems more appropriate to use ms for all cases.
In addition to directly converting ST to US, NO TIMEOUT is represented by -1, so special macros are defined for that.
Apart from directly converting ST to US, the system clock is also in US, for example, when obtaining the current time.
All applications should be converted to ms.

TRANS_BY_GPT3

SrsSource has many functions, but in reality, only the origin server is effective, such as DVR, HLS, Forward, and Transcode. Although the edge server may also trigger these functions, it is actually meaningless. Therefore, these functions of the origin server can be placed on an OriginHub, just like a hub where DVR, HLS, Forward, and Transcode are all connected.

For example, the configuration vhost.play.queue_length should conceptually only be applied to the play or downstream edge, which means it should be related to the connections involved in play. Currently, it is being applied to the upstream edge and forward as well, which is actually incorrect. It should be configured in their respective configuration fields, such as vhost.forward.queue_length.

In addition, the SH and metadata of the cache in the Source can be placed in an aggregated data object. It would be better to have an object to manage these caches instead of scattering them into separate objects.

TRANS_BY_GPT3

There is another type of problem, which is set_cid and get_cid. In fact, the cid of a thread should be given a chance to be specified at creation. For example, the recv thread in the rtmp connection must have the same id as the service cycle thread of the connection, both representing this connection. This means that cid is more of a logical unit for business, rather than the id of a coroutine. A business unit may involve multiple coroutines, but should only have one id.

TRANS_BY_GPT3

In addition, HTTP is the core function of SRS, so SRS3 must enable HTTP. The related macro definitions do not need to be checked, they must be set to TRUE. For example, the macro definition SRS_AUTO_HTTP_CALLBACK does not need to be checked.

The options SRS_HTTP_CALLBACK, SRS_HTTP_SERVER, and SRS_HTTP_API can no longer be disabled. If they are disabled, a warning will be given, but the HTTP functionality will still be enabled.

--without-http-api
--without-http-server
--without-http-callback

TRANS_BY_GPT3

Keep the constructor simple, such as an empty constructor, just to create objects. Refer to 308c6fe and #786. SrsTcpClient uses SrsStSocket, and the constructor of SrsStSocket does not simply require the FD to be passed in. This FD can only be obtained after TcpClient connects, so TcpClient can only construct the StSocket object after connecting, instead of being able to construct it in the constructor. TcpClient provides the interface get_recv_bytes, which can be called after construction (calling the interface of StSocket returns 0), but if StSocket is NULL after construction, it will crash. This violates the integrity of the concept because the non-simple constructor causes a conflict in the interface concept.

TRANS_BY_GPT3

Fixed in #1230