Browser-based data communication method, system and equipment and storage medium

Abstract

The invention provides a browser-based data communication method, system and device, and a storage medium. The method comprises the following steps: receiving message data based on a real-time message transmission protocol from a server; determining a current data analysis state; executing a data reading process corresponding to the current data analysis state on the message data, and switching to the next data analysis state when a switching condition of the next data analysis state is met; and when the current data analysis state is the last data analysis state and the length of the read message data is greater than or equal to the preset complete message length, resetting the current data analysis state as the first data analysis state, processing the read message data, and resetting the length of the read message data. By adopting the method and the device, an asynchronous data transmission architecture between the browser side and the server side is constructed, a browser operation mechanism is adapted, and a data communication mechanism that the browser supports a real-time message transmission protocol is realized.

Description

Background Art

[0002] RTMP (Real-Time Messaging Protocol) is a private protocol launched by Adobe. RTMP was developed by Adobe to facilitate data transmission between the browser flash plug-in and its own streaming media server. Currently, some browsers no longer support flash playback, and Adobe has also announced that it will give up support for flash. How to play RTMP protocol media in the browser has become a problem. However, with the development of mobile devices and modern browsers, the demand for cross-platform support for the RTMP protocol is increasing.

[0003] The existing RTMP protocol uses a synchronous blocking process to implement both streaming and pushing during the communication process. That is, during the program execution, when a function or operation is called, the program will pause at this call and wait until the operation is completed before continuing to execute the next instruction. When the existing desktop client interacts with the server through the RTMP protocol, the desktop client needs to execute a loop to read data. The browser generally uses asynchronous communication to receive and send data. Once synchronous blocking occurs, the browser will directly end the current session process, making it difficult to directly support the RTMP protocol. Summary of the invention

[0004] In response to the problems in the prior art, the purpose of this application is to provide a browser-based data communication method, system, device and storage medium, to construct an asynchronous data transmission architecture between the browser and the server, to adapt to the browser's asynchronous operation mechanism, and to implement a data communication mechanism in which the browser supports a real-time message transmission protocol, without being restricted by the browser type and the content of the installed plug-in.

[0005] The present application provides a browser-based data communication method, comprising the following steps:

[0006] Receive message data based on real-time message transmission protocol from the server;

[0007] Determine the current data parsing status;

[0008] Execute the data reading process corresponding to the current data parsing state on the message data, and switch the current data parsing state to the next data parsing state when the transition condition to the next data parsing state is met;

[0009] When the current data parsing state is the last data parsing state and the length of the read message data is greater than or equal to the preset complete message length, the current data parsing state is reset to the first data parsing state, the read message data is processed, and the length of the read message data is reset.

[0010] By adopting the data communication method of the present application, when data is transmitted between the browser and the server, after the browser receives the message data based on the real-time messaging protocol from the server, the traditional desktop client's cyclic data reading process is not adopted. Instead, the flow processing of the message data received from the browser is realized through a session state tracking mechanism that tracks the RTMP session operation status, thereby realizing asynchronous event-driven RTMP protocol communication between the browser and the server, better adapting to the asynchronous operation mechanism of the browser, and removing the obstacles for the browser to receive real-time messaging protocol data, without being restricted by the browser type and the content of the installed plug-in.

[0011] In some embodiments, before receiving message data based on the real-time message transmission protocol from the server, the following steps are also included:

[0012] Send the first handshake notification data to the server;

[0013] Receive handshake response data from the server;

[0014] Determine the current handshake state, and judge whether the next handshake state transition condition is met according to the handshake response data. If so, switch the current handshake state to the next handshake state;

[0015] When the current handshake state switches to the last handshake state, confirm that the handshake is completed.

[0016] In some embodiments, the handshake state includes a handshake initial state, a first handshake state, a second handshake state, and a third handshake state;

[0017] The current handshake state is the initial handshake state, and when the handshake response data is received for the first time, it switches to the first handshake state;

[0018] When the current handshake state is the first handshake state and the length of the unprocessed handshake response data is greater than or equal to the length of the first handshake response data, send the second handshake notification data to the server, reset the length of the unprocessed handshake response data, and switch to the second handshake state;

[0019] When the current handshake state is the second handshake state and the length of the unprocessed handshake response data is greater than or equal to the second handshake response data length, the connection configuration data is sent to the server and the state is switched to the third handshake state to determine that the handshake is completed.

[0020] In some embodiments, when the current data parsing state is the last data parsing state, it is determined whether the length of the message data read in this state cycle is greater than or equal to the preset message block length;

[0021] If the length of the message data read in this state cycle is greater than or equal to the preset message block length, the current data parsing state is reset to the first data parsing state, and it is determined whether the length of the read message data is greater than or equal to the preset complete message length; if the length of the read message data is greater than or equal to the preset complete message length, the read message data is processed and the length of the read message data is reset; if the length of the read message data is less than the preset complete message length, the read message data is not processed;

[0022] If the length of the message data read in this state cycle is less than the preset message block length, the current data parsing state is maintained as the last data parsing state, and the read message data is not processed.

[0023] In some embodiments, before receiving message data based on the real-time message transmission protocol from the server, the following steps are also included:

[0024] The browser establishes a data transmission channel with the server through the websocket relay service, wherein an RTMP transmission channel is established between the browser and the websocket relay service, and a TCP transmission channel is established between the websocket relay service and the server.

[0025] In some embodiments, the data parsing state includes a parsing initialization state, a parsing basic header state, a parsing message header state, a parsing timestamp state, and a parsing message payload state;

[0026] When the current data parsing state is the parsing initialization state, the basic header byte length is determined according to the unread message data, and when the length of the unread message data is greater than 0, it is switched to the parsing basic header state;

[0027] When the current data parsing state is the basic header parsing state, the basic header byte length is read according to the unread message data, and when the length of the read message data is greater than or equal to the basic header length, the state is switched to the message header parsing state;

[0028] When the current data parsing state is the message header parsing state, determine the message header type and read the message header information, and when the length of the read message data is greater than or equal to the message header length, switch to the timestamp parsing state;

[0029] When the current data parsing state is the timestamp parsing state, read the timestamp, and when the length of the unread message data is greater than 0, switch to the message payload parsing state.

[0030] In some embodiments, the data communication method is implemented based on librtmp, and the data communication method is set on the browser side after being compiled through webassembly.

[0031] The embodiment of the present application further provides a browser-based data communication system, which is applied to the above-mentioned browser-based data communication method, and the system includes:

[0032] A message receiving module, used for receiving message data based on a real-time message transmission protocol from a server;

[0033] A state determination module, used to determine the current data parsing state;

[0034] The state switching module is used to execute the data reading process corresponding to the current data parsing state on the message data, and switch the current data parsing state to the next data parsing state when the transition condition of the next data parsing state is met;

[0035] The data processing module is used to reset the current data parsing state to the first data parsing state, process the read message data, and reset the length of the read message data when the current data parsing state is the last data parsing state and the length of the read message data is greater than or equal to the preset complete message length.

[0036] By adopting the data communication system of the present application, when data is transmitted between the browser and the server, after the browser receives the message data based on the real-time messaging protocol from the server, the traditional desktop client's cyclic reading data process is not adopted. Instead, the flow processing of the message data received from the browser is realized through the session state tracking mechanism, and the RTMP protocol communication based on the asynchronous event-driven type is realized between the browser and the server, which better adapts to the asynchronous operation mechanism of the browser, removes the obstacles of the browser receiving the real-time messaging protocol data, and is not restricted by the browser type and the content of the installed plug-in.

[0037] The embodiment of the present application also provides a browser-based data communication device, including:

[0038] processor;

[0039] a memory in which executable instructions for the processor are stored;

[0040] The processor is configured to execute the steps of the above-mentioned browser-based data communication method by executing executable instructions.

[0041] By adopting the browser-based data communication device provided by the present application, the processor executes the above-mentioned browser-based data communication method when executing executable instructions, thereby obtaining the beneficial effects of the above-mentioned browser-based data communication method.

[0042] The embodiment of the present application also provides a computer-readable storage medium for storing a program, which implements the steps of the above-mentioned browser-based data communication method when executed by a processor.

[0043] By adopting the computer-readable storage medium provided by the present application, the program stored therein implements the steps of the above-mentioned browser-based data communication method when being executed, thereby obtaining the beneficial effects of the above-mentioned browser-based data communication method. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings.

[0045] Figure 1 is a flow chart of a browser-based data communication method according to an embodiment of the present application;

[0046] Figure 2 This is a flowchart of a handshake between a browser and a server in one embodiment of the present application;

[0047] Figure 3 This is a flow chart of the browser side parsing and processing received data in one embodiment of the present application;

[0048] Figure 4 This is a flow chart of a browser side parsing and processing data and then pushing the stream in an embodiment of the present application;

[0049] Figure 5 This is a flow chart of a browser and a server communicating via a transfer service according to an embodiment of the present application;

[0050] Figure 6 is a schematic diagram of a browser-based data communication system according to an embodiment of the present application;

[0051] Figure 7 is a schematic diagram of the structure of a browser-based data communication device according to an embodiment of the present application;

[0052] Figure 8 It is a schematic diagram of the structure of a computer storage medium according to an embodiment of the present application. DETAILED DESCRIPTION

[0053] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this application will be comprehensive and complete and the concepts of the example embodiments will be fully conveyed to those skilled in the art. The same reference numerals in the figures represent the same or similar structures, and thus their repeated description will be omitted. Although "first" or "second" etc. are used in this specification to represent certain features, they are only used to represent the function and are not used as a limitation on the number and importance of specific features.

[0054] In order to solve the technical problems in the prior art, the present application provides a browser-based data communication method, which parses and processes the message data based on the real-time messaging protocol received by the browser from the server. The real-time messaging protocol is RTMP, which is a data transmission technology for real-time video streaming. The RTMP protocol can maintain a persistent connection, so it is particularly suitable for real-time streaming media transmission, fully guaranteeing real-time communication. When users watch live broadcasts online, the RTMP protocol can obtain real-time video content from the video source and send it to the server, and then distribute the video from the server to the user. The RTMP protocol can minimize the delay between capturing the video and displaying the video to the viewer, ensuring that the audience experiences the real-time video stream in near real time. Low latency is essential for interactive streaming media (such as live games, auctions, or sports events) where real-time viewer feedback is critical. The RTMP protocol has a wide range of compatibility and can adapt well to today's diverse device environment. The RTMP protocol supports streaming to a variety of devices, including computers, mobile devices, and smart TVs. This wide compatibility makes RTMP a versatile choice for content creators and online streaming platforms. The RTMP protocol can reach more audiences without worrying about device limitations. Mobile streaming, in particular, benefits from RTMP's efficient transmission to smartphones and tablets, allowing viewers to enjoy live broadcasts anytime, anywhere.

[0055] like Figure 1 As shown, in one embodiment, the browser-based data communication method is deployed on the browser side, which is the browser-based client. The method specifically includes the following steps:

[0056] S100: receiving message data based on a real-time message transmission protocol from a server;

[0057] Here, the server side is the server side that provides streaming media services. It interacts with the browser side. When the browser side is used as the video viewer, it pulls the stream from the server side and plays it. When the browser side is used as the video source side, it pushes the collected streaming media data to the server side, that is, pushes the stream to the server side.

[0058] Receiving message data from the server means that the browser and the server establish a connection and receive message data from the server after the handshake is completed. When the browser pulls the stream and pushes the stream, the message data received from the server includes protocol control messages, connection configuration messages, media data, etc. When the browser pushes the stream to the server, the messages received from the server include protocol control messages and connection configuration messages, etc.

[0059] S200: Determine the current data parsing status;

[0060] In this embodiment, the data parsing process between the browser and the server during the RTMP session is divided into multiple data parsing states, each of which reflects the parsing progress of the data received from the server by the current browser, and also reflects the current RTMP session operation state. This application establishes a session state conversion mechanism based on an asynchronous data transmission architecture, tracks the current RTMP session operation state, and uses each data parsing state as an operation node. It can track which stage the current RTMP session has reached, so that the browser can continue to execute the session process according to the session operation state when receiving data later, thereby adapting the browser operation mechanism;

[0061] S300: executing a data reading process corresponding to the current data parsing state on the message data, and switching the current data parsing state to the next data parsing state when a transition condition to the next data parsing state is met;

[0062] This application determines the current state of message data reception and parsing by tracking and switching the state nodes, and realizes the normal flow processing of message data in asynchronous data transmission mode;

[0063] S400: When the current data parsing state is the last data parsing state, and the length of the read message data is greater than or equal to the preset complete message length, the current data parsing state is reset to the first data parsing state, the read message data is processed, and the length of the read message data is reset. In this embodiment, the data parsing process is divided into a plurality of relatively independent and sequentially executed stages, each stage corresponding to a data parsing state. For a single message block, the initial stage of data parsing of the message block is the first data parsing state, and the last stage of data parsing of the message block is the last data parsing state. After the last data parsing state is completed, it indicates that the parsing of the message block is completed, and it can be reset back to the first data parsing state at this time to indicate the start of data parsing of the next message block.

[0064] Reading the message data here refers to parsing the message data and reading it into the cache.

[0065] By adopting the data communication method of the present application, when data is transmitted between the browser and the server, after the browser receives the message data based on the real-time messaging protocol from the server, the traditional desktop client's cyclic data reading process is not adopted. Instead, the flow processing of the message data received from the browser is realized through a session state tracking mechanism that tracks the RTMP session operation status, thereby realizing asynchronous event-driven RTMP protocol communication between the browser and the server, better adapting to the asynchronous operation mechanism of the browser, and removing the obstacles for the browser to receive real-time messaging protocol data, without being restricted by the browser type and the content of the installed plug-in.

[0066] In this embodiment, the data communication method is implemented based on librtmp. Currently, only the protocol text of the RTMP protocol has been published. Many open source contributors have reversely developed some protocol parsing libraries, such as librtmp, based on its protocol. Librtmp is used in a variety of open source audio and video codec solutions. Since librtmp is an application layer communication protocol based on the TCP (Transmission Control Protocol) protocol, close to the operating system level, and in order to efficiently complete the packet grouping and subpackaging of messages, the entire library is currently written entirely in C language, and the internal single-threaded synchronous blocking model. Librtmp is an open source C language-based library that provides an API for sending and receiving RTMP streams. It can be used to develop applications such as streaming media players and live webcasts. The main features of Librtmp are fast, stable and low latency. Librtmp supports multiple protocols such as RTMP, RTMPS, RTMPE and RTMPTE encryption protocols. In addition, it also supports the proxy server protocols of PProxy, PPlayer and appspot. Under Linux, applications developed using librtmp can support multiple system platforms such as Windows and Android. This application improves the synchronous blocking model inside librtmp and builds an asynchronous communication architecture. Librtmp is set in the application layer and implements its internal logic through javascript calls. Therefore, the data transmission of this application is driven by the upper application layer, and the data processing step of the RTMP protocol can be synchronously triggered according to the browser-side onMessage network data callback.

[0067] The following describes the execution process of the session flow function of the RTMP protocol session between the client and the server. The RTMP protocol session process mainly includes three processes: handshake, connection establishment and stream establishment.

[0068] (1)shake hands

[0069] The RTMP connection starts with a handshake. Different from the TCP handshake, it is implemented by including three fixed-size message blocks. The three message blocks sent by the client are named C0, C1, and C2; the three message blocks sent by the server are named S0, S1, and S2.

[0070] The handshake sequence is as follows:

[0071] The client starts the handshake process by sending C0 and C1 messages. The client must receive the S1 message returned by the server and then send the C2 message. The client must receive the S2 message returned by the server and then send subsequent other data.

[0072] The server must receive the C0 or C1 message and then send the S0 and S1 messages. The server must receive the C2 message and then send the subsequent other data.

[0073] (2) Establishing a connection

[0074] The client sends a connection command (connect) in a command message to the server, requesting to establish a connection with a service application instance.

[0075] After receiving the connection command message, the server sends a Window AcknowledgementSize protocol message to the client and connects to the application mentioned in the connection command.

[0076] The server sends a Set Peer Bandwidth message to the client.

[0077] After the client processes the bandwidth setting protocol message, it sends a window size confirmation (Window AcknowledgementSize) protocol message to the server.

[0078] The server sends a stream start command (Stream Begin) message in the user control message to the client.

[0079] The server sends a result notification (result) in the command message to inform the client of the status of the connection.

[0080] (3) Establishing a flow

[0081] (3.1) The process of the client pulling the stream synchronously from the server is as follows:

[0082] The client sends the (play) command after receiving the successful result (result) of the stream creation command (createstream) from the server.

[0083] After receiving the play command, the server sends a message chunk size setting message to set the chunk message length (SetChunkSize).

[0084] The server sends another user control message, specifying the event "stream recorded" (StreamIsRecorded) and the stream ID. The first 2 bytes of this message carry the event type, and the last 4 bytes carry the stream ID.

[0085] The server sends another user control message, specifying the event "StreamBegin", to indicate the start of the stream to the client.

[0086] If the play command sent by the client is successful, the server sends the command message (onStatus), NeStream.Play.Start & NeStream.Play.Reset. The server will send NeStream.Play.Reset only if the play command sent by the client sets the reset flag. If the stream to be played is not found, the server will send the onStatus message NeStream.Play.StreamNotFound.

[0087] After that, the client plays the audio and video data sent by the server. After receiving the data, the client reads the cached data in the message block size, parses the basic header, message header, and timestamp information of the message block, and writes the media file if the complete message block has been received. If the complete message block has not been received, the length of the message block read is updated according to the remaining unread data length and the default message block size. After receiving the stream end command, the client sends an end confirmation to the server to end the streaming process.

[0088] (3.2) The process of synchronous streaming from the client to the server is as follows:

[0089] The client sends the (play) command after receiving the successful result (result) of the stream creation command (createstream) from the server.

[0090] After receiving the play command, the server sends a message chunk size setting message to set the chunk message length (SetChunkSize).

[0091] The client passes the video stream data to be sent to the server from the application, segments the data according to the message block size, and then sends each message block to the server.

[0092] During the RTMP session between the client and the server, after the handshake between the client and the server is successful, the data received by the client from the server needs to be parsed and processed. When the client pulls the stream synchronously from the server, the data received by the client from the server includes configuration data and video stream data, and when the client pushes the stream synchronously to the client, the data received by the client from the server mainly includes configuration data. The handshake process and data parsing process of the existing RTMP session both adopt the synchronous blocking strategy. The client needs to receive specific data from the server before continuing to the next step, otherwise it will remain at the current stage.

[0093] In the prior art, there is no direct compatibility between the RTMP protocol and the interaction mechanism of the browser. The RTMP protocol process is essentially a conversation process. The interaction process of this conversation needs to be driven by network data. Each conversation interaction and the advancement of each link depend on the data uploaded on the network. In the traditional conversation, after completing a conversation node, the client will receive the data required for the next conversation node through the network communication interface of the operating system. If the required data is not received, the program conversation function process will be blocked and the conversation function process will not continue to be executed until the required amount of data is received. For example, after the client sends a certain data to the server, it must wait until the server responds to the data accordingly before the client continues to send the following data, otherwise it will be blocked at the current stage and will not continue to execute the conversation function process. Therefore, after completing a conversation node, the traditional desktop client will cyclically read the data of the network communication interface. If the data returned by the server is not received, the network communication interface will continue to be cyclically read.

[0094] However, the browser environment is different from the desktop client environment. There is no network communication interface on the browser side to receive data, so it is impossible to use a fixed network communication interface to receive data related to the RTMP protocol session. In the browser, the acquisition of program data depends entirely on how the browser provides it. The browser provides data irregularly each time, and the size and frequency interval of the data provided to the program each time are random. According to the processing characteristics of the browser, in order to ensure its overall running smoothness and user experience, it does not allow the program to be blocked at a certain stage by waiting for data like the traditional method. Once the browser side finds that the session process is blocked, the browser will actively intervene and forcibly terminate the current session function process of the program. When the browser receives subsequent data, it does not know which stage the previous session process has reached, so it cannot continue the previous session process and continue to execute the subsequent session function process.

[0095] Therefore, when the browser executes the program session function again, it is necessary to track the completed session stage and continue to execute it, and then execute the subsequent session flow function, so that the overall session process maintains the continuity in the process. Otherwise, when the server finds that the overall session process is incoherent and lacks the key link connection, it will be considered that the current session is invalid in the overall session process, and it is also impossible to continue to implement the session process between the server and the client. Based on this, the present invention is divided into different session operation states (such as data parsing state and handshake state mentioned later) by reconstructing the RTMP session process, and the RTMP session operation state is converted and tracked. When the browser exits the current session due to blocking, after receiving data from the server again, the corresponding session flow function can be continued to be executed according to the current session operation state, and the key session node will not be missing, so as to maintain the session fluency and session link integrity between the browser and the server, so that the RTMP session process between the browser and the server can be continuously and smoothly executed.

[0096] In the prior art, the RTMP protocol is supported in the browser mainly through the following methods:

[0097] (1) With the help of third-party libraries: Use JavaScript libraries such as video.js, which supports playing RTMP streams through flash. However, since flash is no longer supported in modern browsers, this method may be limited in newer versions of browsers.

[0098] (2) Using HTML5 Video element: Although HTML5 <video>The tag does not support the RTMP protocol, but you can play the video by adding a source file type that supports RTMP. However, this usually requires relying on specific browser support or third-party software implementation, which brings a lot of adaptation work.

[0099] (3) Online protocol conversion on the service side: Use tools such as FFmpeg (an open source software project for processing audio, video, and other multimedia files) to parse the RTMP stream into other formats, such as HLS (HTTP Live Streaming, an HTTP streaming protocol), and then play it on the browser side through a player that supports HLS. This process may increase playback latency and require additional resources and processing power.

[0100] (4) Use a dedicated player: Use a dedicated player that supports RTMP streaming, but this usually requires users to install additional plug-ins in the browser or use specific browser configurations. Users may encounter security prompts or need to manually enable plug-ins when accessing RTMP streams, which affects the user experience.

[0101] It can be seen from the above methods that the methods of supporting RTMP protocol on the browser side in the prior art basically need to be implemented by installing additional plug-ins in the browser or using other special playback tools, which brings great inconvenience to users. In this embodiment, after the data communication method is compiled to form a script code, the script code is embedded in the program on the browser side, so that the native browser side can have the function of the data communication method without installing additional plug-ins or using additional special tools. For example, the data communication method is set on the browser side after being compiled by webassembly. Webassembly (abbreviated as wasm) is a virtual instruction set architecture (virtual ISA), and the overall architecture includes the core ISA definition, binary encoding, definition and execution of program semantics, and application programming interface (WebAssembly API) for different embedded environments (such as Web). Its initial goal is to compile programs written in languages ​​such as C / C++, and run on the Web platform based on better running speed while ensuring security and close to native applications. Since Webassembly does not support native IO, the native network IO involved in librtmp is removed, and the network data input interface and output interface callback are added to the web application for upper-level calls. By compiling the data communication method through webassembly and setting it on the browser side, there is no need to set up plug-ins and other additional dedicated playback tools separately, thereby realizing an RTMP protocol process with close to native performance on the browser side, making it more convenient for users to use.

[0102] In this application, the protocol session opening entry is triggered by the upper layer application, and the upper layer application synchronously performs active handshake notification data transmission. The protocol session ends when the server actively closes, the application closes, or the application network error times out. Therefore, the protocol session termination nodes include active termination by the server, application termination, application network error timeout, etc.

[0103] Under the browser message-driven mechanism, both receiving and sending data need to be implemented through the browser side, and the original active sending and receiving of data needs to be changed to message receiving and distribution. Due to the sticky packet problem in the TCP protocol, the protocol layer cannot perceive the required number of data reception. The sticky packet problem is a situation often encountered in computer networks, especially when using stream-oriented transmission protocols (such as TCP). It mainly involves the organization and reception of data during transmission. When using the TCP protocol for data transmission, the sender often divides the data to be transmitted into small data blocks and sends them to the receiver through the network. However, the underlying network transmission usually does not guarantee that the receiver can accurately receive data according to the sender's data block boundaries. This may cause multiple small data packets to be merged into a large data block during transmission, which is called the sticky packet problem. Therefore, the present application further performs byte legacy management on the data received by the network each time, and manages the data remaining from the current message processing, that is, at each data parsing and processing, the current remaining data is uniformly processed.

[0104] Before the browser and the server communicate messages, after the data transmission channel is established between the browser and the server, the browser and the server shake hands. The RTMP session between the browser and the server mainly includes a handshake process and a data parsing process, so the RTMP session operation status can be represented by the handshake state in the handshake process and the data parsing state in the data parsing process. Each handshake state corresponds to each session state node in the handshake process, and the data parsing state corresponds to each session state node in the data parsing process. The present application establishes an RTMP session state conversion and tracking mechanism to track the current RTMP session operation node and abandons the original cyclic data reading process. In this embodiment, an asynchronous communication method is used for handshake to adapt to the browser's data transmission mechanism. Based on this, the present application adds a handshake state through reconstruction. Such as Figure 2 As shown, the handshake state includes the handshake initial state Handshake_unint, the first handshake state Handshake_0, the second handshake state Handshake_1 and the third handshake state Handshake_2. The handshake initial state Handshake_unint indicates the beginning stage of the handshake between the browser and the server. After reaching the last handshake state, that is, the third handshake state Handshake_2, the handshake is considered to be completed.

[0105] like Figure 2 As shown, before the step S100: receiving message data based on the real-time message transmission protocol from the server, the following steps are also included:

[0106] The first handshake notification data C0 and C1 are sent to the server; the browser starts the handshake process by sending C0 and C1 data;

[0107] Receive handshake response data from the server;

[0108] Determine the current handshake state, and judge whether the next handshake state transition condition is met according to the handshake response data. If so, switch the current handshake state to the next handshake state;

[0109] When the current handshake state switches to the last handshake state, confirm that the handshake is completed.

[0110] like Figure 2 As shown, after the browser is initialized and has not received any data from the server, the current handshake state is in the handshake initial state Handshake_unint.

[0111] The current handshake state is the handshake initial state Handshake_unint. After the browser sends C0 and C1 data to the server, when it receives the handshake response data for the first time and the data length of the handshake response data is greater than 0, it switches to the first handshake state Handshake_0.

[0112] In the handshake phase, the server needs to send S0 and S1 messages after receiving C0 and C1. The browser needs to send the second handshake notification data C2 after receiving the S1 message sent by the server. Set the length of the S0 message and the S1 message to the first handshake response data length. The server needs to send the S2 message after receiving the C2 message. The browser must send the connection configuration data after receiving the S2 message. Set the length of the S2 message to the second handshake response data length.

[0113] When the current handshake state is the first handshake state Handshake_0, and the length of the unprocessed handshake response data (the sum of the length of the data received this time and the length of the unprocessed data remaining last time) is greater than or equal to the length of the first handshake response data, it means that the browser has received the S1 message, sends the second handshake notification data C2 to the server, resets the length of the unprocessed handshake response data (sets the part corresponding to the length of the first handshake response data as processed), and switches to the second handshake state Handshake_1.

[0114] In the handshake phase, when the current handshake state is the second handshake state Handshake_1, and the length of the unprocessed handshake response data (the sum of the length of the data received this time and the length of the unprocessed data left over from the last time) is greater than or equal to the length of the second handshake response data, it indicates that the browser has received the S2 message, sends the connection configuration data to the server, and switches to the third handshake state Handshake_2 to confirm that the handshake is complete. The connection configuration data includes the node directory in the RTMP push and pull stream address, the playback capability during the pull stream, the audio and video codec, the byte serialization method, etc.

[0115] After the handshake is completed, the browser and the server establish a connection in the following ways:

[0116] The browser sends the "connect" command message to the server, requesting to establish a connection with a service application instance; after receiving the connection command message, the server sends a Window AcknowledgementSize protocol message to the browser, and connects to the application mentioned in the connection command; the server sends a Set Peer Bandwidth protocol message to the browser; after processing the Set Peer Bandwidth protocol message, the browser sends a Window Acknowledgement Size protocol message to the server; the server sends a "Stream Begin" message in the user control message to the browser; the server sends a "result" in the command message to inform the browser of the connection status.

[0117] After the connection is established, the stream is established in the following ways: the browser sends a (play) command after receiving the successful result (_result) of the stream creation command (createstream) from the server; the server sends a message to set the chunk size (SetChunkSize) after receiving the play command; the server sends another user control message, specifying the event "stream record" (StreamIsRecorded) and the stream ID. The first 2 bytes of this message carry the event type, and the last 4 bytes carry the stream ID; the server sends another user control message, specifying the event "stream start" (StreamBegin), to indicate the start of the stream to the browser; if the play (play) command sent by the browser is successful, the server sends a command message (onStatus), NeStream.Play.Start & NeStream.Play.Reset. The server will only send NeStream.Play.Reset if the play command sent by the browser sets the reset flag. If the stream to be played is not found, the server will send the onStatus message NeStream.Play.StreamNotFound. After that, the browser plays the audio and video data sent by the server.

[0118] In this embodiment, after the handshake between the browser and the server is completed, the browser receives the message from the server, parses it, and then processes the message. Parsing at this stage refers to the process of extracting the message header, message type, message length, message timestamp, etc. of the message and reading the message data into the cache. Processing at this stage refers to message processing for different message types, such as extracting raw data from media data messages and playing them, configuring the connection status based on the message content for connection configuration messages, and controlling the protocol transmission process based on the message content for protocol control messages.

[0119] After the RTMP handshake is completed, the message data received is sent in the form of RTMP chunks. In the RTMP protocol, Chunk is the basic unit of data transmission, which is used to transmit audio, video or other types of streaming media data and control information between the client and the server. The RTMP protocol uses this Chunk method to improve transmission efficiency and flexibility. It allows data to be divided into smaller parts for transmission, which can better adapt to different network environments and data types.

[0120] In this embodiment, the message data received by the browser from the server each time may be only a part of a message block. For each message block, it is necessary to completely parse through each data parsing state, and then reset the data parsing state to the initial parsing state, and then start parsing the next message block. Multiple message blocks constitute a complete message. After determining that a complete message has been read, the read message is processed. If a complete message has not been read, the subsequent message blocks are parsed and processed.

[0121] Therefore, in step S400, when the current data parsing state is the last data parsing state, it is determined whether the length of the message data read in this state cycle is greater than or equal to the preset message block length. This state cycle refers to a complete cycle that runs unidirectionally from the first data parsing state to the last data parsing state. For each message block, it is necessary to ensure that the message block can complete a complete state cycle, that is, for each message block, the data parsing state at the beginning is the first data parsing state. As the data of the message block is gradually received and parsed, the data parsing state gradually advances unidirectionally. When all the data parsing of the message block is completed, the data parsing state should be the last data parsing state, and then reset to the first data parsing state, and then start the parsing process of the next message block.

[0122] If the length of the message data read in this state cycle is greater than or equal to the preset message block length, it means that the current message block has been parsed, the current data parsing state is reset to the first data parsing state, and it is determined whether the length of the message data read is greater than or equal to the preset complete message length. If the length of the message data read is greater than or equal to the preset complete message length, it means that the reading of a complete message has been completed, the read message data is processed, and the length of the read message data is reset. If the length of the message data read is less than the preset complete message length, it means that the current message data read is not enough to form a complete message, and it is necessary to wait for the subsequent message block, and the read message data is not processed. The processing here specifically refers to different message processing according to the message type after the message is parsed and cached into the memory, such as media data playback. It is equivalent to setting two separate message length counts, one count is the count of the length of the read message starting from the first data parsing state, when the count reaches the length of the message block, it is considered that the parsing of a message block has been completed, and when it is reset back to the first data parsing state, the count value is also cleared to count the message length of the next message block, ensuring that each message block completes a complete data parsing state cycle. Another count is the count of data that has been read but not processed. When the amount of data in this count reaches the amount of data in a message, data processing is performed. When a complete message is processed, the count value of the data that has been read but not processed is cleared to zero and used for counting subsequent messages to ensure that each message can be processed as a complete message and that there is no mutual interference between the previous and subsequent messages.

[0123] If the length of the message data read in this state cycle is less than the preset message block length, it means that the current message block has not been received and parsed. The current data parsing state is maintained as the last data parsing state, and subsequent message data continues to be received, and the read message data is not processed.

[0124] According to the RTMP chunk packet structure, the parsing of the packet has clear steps, and because of the orderliness of TCP data transmission, the process state between chunk unpacking and assembly is continuous. Therefore, the chunk packet parsing stage is divided into multiple data parsing states.

[0125] like Figure 3 As shown, the data parsing status includes:

[0126] Parse initialization status PARAE_INT;

[0127] Parse basic header status PARAE_BASIC_HEADER;

[0128] Parse the message header status PARAE_MESSAGE_HEDER;

[0129] Parsed timestamp status PARAE_EXTENDED_TIMESTAMP; and

[0130] Parse the message payload status PARAE_PAYLOAD.

[0131] When the current data parsing state is the parsing initialization state, it indicates that the message data received after the first parsing processing Handshake_2 state or that the previously received message data has been completely parsed into a chunk data packet.

[0132] When the current data parsing state is the parsing initialization state, the message data is received and the basic header byte length is determined based on the unread message data, and when the length of the unread message data is greater than 0, it switches to the parsing basic header state. The unread message value here is the data that has not been parsed and read into the cache, including the data received this time and the unread data left over from the previous time.

[0133] When the current data parsing state is the basic header parsing state, the basic header byte length content is read into the cache according to the unread message data, and when the length of the read message data is greater than or equal to the basic header length, it is switched to the message header parsing state.

[0134] When the current data parsing state is the message header parsing state, determine the message header type and read the message header information into the cache, and when the length of the read message data is greater than or equal to the message header length, parse and obtain cid (channel identifier), streamid (stream data identifier), timestamp, content length, message type, etc., and switch to the timestamp parsing state.

[0135] When the current data parsing state is the timestamp parsing state, the timestamp and time difference are read according to the first two digits of the first byte. Specifically, it is determined whether the message header satisfies timestamp===0xFFFFFF to determine whether it is necessary to process the extended time message header. When timestamp===0xFFFFFF, the extended time message header data is read and analyzed. When the message header type is 1, timestamp represents an absolute timestamp, otherwise timestamp represents a time difference. If the extended time message header data reading and analysis is required, and the four bytes of the message data need to be processed additionally, the chunk data packet memory structure is allocated (packet memory is allocated), and it is determined whether the length of the unread message data is greater than or equal to 4. If so, it is switched to the message load parsing state. If not, the data processing is terminated and the next message data is waited for to arrive before continuing the processing. If the extended time message header data reading and analysis is not required, it is switched to the message load parsing state.

[0136] like Figure 3 As shown, when the current data parsing state is the parsing message load state, it is determined whether the data read in this cycle is greater than or equal to the chunk length. Here, this cycle is a single cycle from the initial parsing state to the parsing message load state. If the data read in this cycle is less than the chunk length, the current data parsing state is maintained as the parsing message load state, and message data continues to be received from the server. If the data read in this cycle is greater than or equal to the chunk length, the read length is determined based on the minimum principle of the unread message data length and the length to be read, and the corresponding message data is read from the unread message data into the cache based on the determined read length.

[0137] Here, determining the read length based on the minimum principle of the length of the unread message data and the length to be read means: determining the read length based on the smaller one of the current unread message data length and the length to be read. Here, the length to be read is determined by the complete message length, for example, that is, the length of the data currently read into the cache is x, and the length of the complete message is y, then the length to be read is (yx). The length of the currently unread message data is z, and (yx) is compared with z. If (yx) is smaller, the read length is (yx), and the remaining data of z-(yx) is reserved for the next data processing. If z is smaller, the read length is z, and a value smaller than the complete message length y will be obtained when the length of the read data is subsequently calculated.

[0138] Determine whether the length of the data read is greater than or equal to the length of the complete message, which is indicated in the message header with fmt (character format) being 0.1. If the length of the data read is greater than or equal to the length of the complete message, it is determined that a message has been completely read, the length of the data read and the timestamp are reset, and the message is reset to the initial state of parsing. The complete message is processed according to the message type. If the length of the data read is less than the length of the complete message, the data is not processed and the message is reset to the initial state of parsing.

[0139] Figure 2 The handshake process and Figure 3 The data parsing process in can be used in the data pulling and pushing processes. In the data pushing process, the asynchronous handshake and asynchronous data parsing process in the data pulling process can be reused. Among them, the byte serialization process involved in the parsing process can also be encapsulated as a function, so that it can be reused in the pulling and pushing processes. In the data pulling process, after processing the message according to the message type, the data processing can be ended. Figure 4 As shown, in the data streaming process, after processing the message according to the message type, it is determined whether the server publish is received (when the browser needs to send audio, video or other data to the server for distribution, it is necessary to perform the "publish" operation on the server to receive and process these streaming data). If not, the data processing is terminated. If yes, the application is notified to pass in tag data for processing. After the application passes in flv tag data (FLV (Flash Video) is a file format for transmitting video and audio on the Internet, which is widely used in the field of streaming media. FLV files are composed of a series of "tags"), the incoming data is chunked and then sent to the server.

[0140] Since the RTMP protocol is designed based on TCP, the RTMP protocol data sent or received by the RTMP server is transmitted through the TCP channel. However, the browser does not currently support the TCP method. Therefore, this application uses the websocket transfer service (websocket over tcp) to switch the transmission method of the RTMP protocol data between the RTMP server and the browser.

[0141] like Figure 5 As shown, in this embodiment, before receiving message data based on the real-time message transmission protocol from the server, the following steps are also included:

[0142] The browser establishes a data transmission channel with the server through the websocket relay service, where an RTMP transmission channel is established between the browser and the websocket relay service, and a TCP transmission channel is established between the websocket relay service and the server. WebSocket is a protocol for full-duplex communication on a single TCP connection, which enables real-time, two-way data transmission between the client and the server.

[0143] After the browser establishes a data transmission channel with the server through the websocket transfer service, the handshake between the browser and the server and the message transmission including the code stream data are realized through the transfer service.

[0144] Therefore, in this embodiment, librtmp is reconstructed into an asynchronous event-driven model to adapt to the operating mechanism and IO mode of the browser side, and compiled through webassembly, so that the browser side can complete the parsing process of the RTMP protocol in a nearly native way, and realize the transmission communication process between the browser and the server through the websocket over tcp transit service, thereby realizing the RTMP push-pull stream process on the browser side at the lowest cost. When the session between the browser and the server starts, the browser sends the RTMP playback address to the websocket over tcp transit service. The transit service receives the address and parses it to extract the RTMP service IP address port and establishes a TCP connection with the RTMP service. After the link is successfully established, the browser initiates the RTMP protocol interaction process until the code stream is received. At the end of the session, the browser sends a stop signal to the transit service and forwards it to the RTMP service. The transit service disconnects the TCP link with the RTMP service.

[0145] like Figure 6 As shown, the embodiment of the present application also provides a browser-based data communication system, which is applied to the above-mentioned browser-based data communication method, and the system includes:

[0146] The message receiving module M100 is used to receive message data based on the real-time message transmission protocol from the server;

[0147] The state determination module M200 is used to determine the current data parsing state;

[0148] The state switching module M300 is used to execute the data reading process corresponding to the current data parsing state on the message data, and switch the current data parsing state to the next data parsing state when the transition condition of the next data parsing state is met;

[0149] The data processing module M400 is used to reset the current data parsing state to the first data parsing state, process the read message data, and reset the length of the read message data when the current data parsing state is the last data parsing state and the length of the read message data is greater than or equal to the preset complete message length.

[0150] The data communication system is deployed on the browser side and is used to realize asynchronous data communication between the browser side and the server side based on the RTCP protocol. By adopting the data communication system of the present application, when the browser side and the server side transmit data, after the browser side receives the message data based on the real-time message transmission protocol from the server side, it does not adopt the cyclic reading data process of the traditional desktop client, but realizes the flow processing of the message data received from the browser side through the session state tracking mechanism, realizes the rtmp protocol communication based on the asynchronous event-driven type between the browser side and the server side, better adapts to the asynchronous operation mechanism of the browser side, and clears the obstacles of the browser side receiving the real-time message transmission protocol data, and is not limited by the browser type and the content of the installed plug-in.

[0151] In the browser-based data communication system, the functions of each module can be implemented by using the specific implementation methods of each step of the above-mentioned browser-based data communication method, which will not be described in detail here.

[0152] An embodiment of the present application also provides a browser-based data communication device, comprising a processor; a memory, in which executable instructions of the processor are stored; wherein the processor is configured to perform the steps of the browser-based data communication method by executing the executable instructions.

[0153] Those skilled in the art will appreciate that various aspects of the present application may be implemented as a system, method or program product. Therefore, various aspects of the present application may be specifically implemented in the following forms, namely: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software, which may be collectively referred to as "circuit", "module" or "system".

[0154] Refer to the following Figure 7 The electronic device 600 according to this embodiment of the present application is described. Figure 7 The electronic device 600 shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0155] like Figure 7 As shown, the electronic device 600 is in the form of a general computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including the storage unit 620 and the processing unit 610), a display unit 640, etc.

[0156] The storage unit stores a program code, which can be executed by the processing unit 610, so that the processing unit 610 performs the steps of various exemplary embodiments of the present application described in the above-mentioned browser-based data communication method section of this specification. For example, the processing unit 610 can perform the following steps: Figure 1 Follow the steps shown in .

[0157] The storage unit 620 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 6201 and / or a cache memory unit 6202 , and may further include a read-only memory unit (ROM) 6203 .

[0158] The storage unit 620 may also include a program / utility 6204 having a set (at least one) of program modules 6205, such program modules 6205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each of which or some combination may include the implementation of a network environment.

[0159] Bus 630 may represent one or more of several types of bus structures, including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0160] The electronic device 600 may also communicate with one or more external devices 700 (e.g., keyboards, pointing devices, Bluetooth devices, etc.), may also communicate with one or more devices that enable a user to interact with the electronic device 600, and / or communicate with any device that enables the electronic device 600 to communicate with one or more other computing devices (e.g., routers, modems, etc.). Such communication may be performed via an input / output (I / O) interface 650. Furthermore, the electronic device 600 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 660. The network adapter 660 may communicate with other modules of the electronic device 600 via a bus 630. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0161] By adopting the browser-based data communication device provided by the present application, the processor executes the browser-based data communication method when executing the executable instructions, thereby obtaining the beneficial effects of the above-mentioned browser-based data communication method.

[0162] The embodiment of the present application also provides a computer-readable storage medium for storing a program, which implements the steps of the browser-based data communication method when executed by a processor. In some possible implementations, various aspects of the present application can also be implemented in the form of a program product, which includes a program code. When the program product is run on a terminal device, the program code is used to cause the terminal device to execute the steps of various exemplary implementations of the present application described in the above-mentioned browser-based data communication method section of this specification.

[0163] refer to Figure 8 As shown, a program product 800 for implementing the above method according to an embodiment of the present application is described, which can adopt a portable compact disk read-only memory (CD-ROM) and include program code, and can be run on a terminal device, such as a personal computer. However, the program product of the present application is not limited thereto. In this document, a readable storage medium can be any tangible medium containing or storing a program, which can be used by or in combination with an instruction execution system, an apparatus or a device.

[0164] The program product may use any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0165] The computer readable storage medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The readable storage medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by an instruction execution system, an apparatus, or a device or used in combination with it. The program code contained on the readable storage medium may be transmitted with any appropriate medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the above.

[0166] Program codes for performing the operations of the present application may be written in any combination of one or more programming languages, including object-oriented programming languages, such as Java, C++, etc., and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device, partially on a remote computing device, or entirely on a remote computing device or cluster. In the case of a remote computing device, the remote computing device may be connected to the user computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0167] By adopting the computer-readable storage medium provided by the present application, the program stored therein implements the steps of the browser-based data communication method when being executed, thereby obtaining the beneficial effects of the browser-based data communication method.

[0168] The above content is a further detailed description of the present application in combination with specific preferred implementation methods, and it cannot be determined that the specific implementation of the present application is limited to these descriptions. For ordinary technicians in the technical field to which the present application belongs, several simple deductions or substitutions can be made without departing from the concept of the present application, which should be deemed to fall within the scope of protection of the present application.< / video>

Claims

1. A data communication method based on a browser, characterized in that: The steps include: Receive message data based on real-time message transmission protocol from the server; Determine the current data parsing status; Execute the data reading process corresponding to the current data parsing state on the message data, and switch the current data parsing state to the next data parsing state when the transition condition to the next data parsing state is met; When the current data parsing state is the last data parsing state and the length of the read message data is greater than or equal to the preset complete message length, the current data parsing state is reset to the first data parsing state, the read message data is processed, and the length of the read message data is reset.

2. The browser-based data communication method according to claim 1, characterized in that: Before receiving the message data based on the real-time message transmission protocol from the server, the following steps are also included: Sending first handshake notification data to the server; Receiving handshake response data from the server; Determine the current handshake state, and judge whether the next handshake state transition condition is met according to the handshake response data, and if so, switch the current handshake state to the next handshake state; When the current handshake state switches to the last handshake state, confirm that the handshake is completed.

3. The browser-based data communication method according to claim 2, characterized in that: The handshake state includes an initial handshake state, a first handshake state, a second handshake state and a third handshake state; The current handshake state is the initial handshake state, and when the handshake response data is received for the first time, it switches to the first handshake state; When the current handshake state is the first handshake state and the length of the unprocessed handshake response data is greater than or equal to the length of the first handshake response data, second handshake notification data is sent to the server, the length of the unprocessed handshake response data is reset, and the state is switched to the second handshake state; When the current handshake state is the second handshake state and the length of the unprocessed handshake response data is greater than or equal to the second handshake response data length, the connection configuration data is sent to the server and the state is switched to the third handshake state to determine that the handshake is completed.

4. The browser-based data communication method according to claim 1, characterized in that: When the current data parsing state is the last data parsing state, it is determined whether the length of the message data read in this state cycle is greater than or equal to the preset message block length; If the length of the message data read in this state cycle is greater than or equal to the preset message block length, the current data parsing state is reset to the first data parsing state, and it is determined whether the length of the message data read is greater than or equal to the preset complete message length; If the length of the read message data is greater than or equal to the preset complete message length, the read message data is processed and the length of the read message data is reset; if the length of the read message data is less than the preset complete message length, the read message data is not processed; If the length of the message data read in this state cycle is less than the preset message block length, the current data parsing state is maintained as the last data parsing state, and the read message data is not processed.

5. The browser-based data communication method according to claim 1, characterized in that: Before receiving the message data based on the real-time message transmission protocol from the server, the following steps are also included: The browser establishes a data transmission channel with the server through the websocket relay service, wherein an RTMP transmission channel is established between the browser and the websocket relay service, and a TCP transmission channel is established between the websocket relay service and the server.

6. The browser-based data communication method according to claim 1, characterized in that: The data parsing status includes parsing initialization status, parsing basic header status, parsing message header status, parsing timestamp status and parsing message payload status; When the current data parsing state is the parsing initialization state, the basic header byte length is determined according to the unread message data, and when the length of the unread message data is greater than 0, it is switched to the parsing basic header state; When the current data parsing state is the basic header parsing state, the basic header byte length is read according to the unread message data, and when the length of the read message data is greater than or equal to the basic header length, the state is switched to the message header parsing state; When the current data parsing state is the message header parsing state, determine the message header type and read the message header information, and when the length of the read message data is greater than or equal to the message header length, switch to the timestamp parsing state; When the current data parsing state is the timestamp parsing state, read the timestamp, and when the length of the unread message data is greater than 0, switch to the message payload parsing state.

7. The browser-based data communication method according to claim 1, characterized in that: The data communication method is implemented based on librtmp, and the data communication method is set on the browser side after being compiled through webassembly.

8. A browser-based data communication system, characterized in that: The browser-based data communication method applied to any one of claims 1 to 7, wherein the system comprises: A message receiving module, used for receiving message data based on a real-time message transmission protocol from a server; A state determination module, used to determine the current data parsing state; A state switching module, used to execute a data reading process corresponding to a current data parsing state on the message data, and switch the current data parsing state to a next data parsing state when a transition condition to a next data parsing state is met; A data processing module is used to reset the current data parsing state to the first data parsing state when the current data parsing state is the last data parsing state and the length of the read message data is greater than or equal to the preset complete message length, process the read message data, and reset the length of the read message data.

9. A browser-based data communication device, characterized in that: include: processor; a memory storing executable instructions of the processor; The processor is configured to perform the steps of the browser-based data communication method according to any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium for storing a program, characterized in that: When the program is executed by a processor, the steps of the browser-based data communication method according to any one of claims 1 to 7 are implemented.

Images