Efficient matching and video and event synchronization method and system for interactive server

Abstract

The invention relates to the technical field of network communication and online services, and discloses an efficient matching and video and event synchronization method and system for an interactive server, and the method comprises the following steps: the server receives a matching request, and achieves efficient user / participant matching through a unique transaction identifier, an asynchronous queue and batch processing; after matching succeeds, the client establishes WSS secure real-time communication with a specified back-end service unit; the server processes the key interaction event, and broadcasts a synchronization event to all clients in a room in a low-delay manner through WSS; and on the basis of the synchronization events, playing or key application states of shared contents of the clients are controlled in a coordinated manner, so that strict synchronization of the shared contents of the clients at key time points is ensured. The system comprises modules for realizing the method. According to the method, the matching efficiency can be remarkably improved, the synchronization of the playing or key application state of the interactive event and the shared content is ensured, the fluency and fairness of user experience are enhanced, and the overall efficiency and stability of the system are optimized.

Description

Technical Field

[0001] The present invention relates to the field of network communication and online service technology, and in particular to an efficient matching, video and event synchronization method and system for an interactive service end. Background Art

[0002] With the rapid development of internet technology and the growing demand for online interactive entertainment, various real-time interactive services (hereinafter referred to as interactive services), such as synchronized movie viewing, collaborative gaming, and online educational interaction, are becoming increasingly popular. The core of these applications lies in providing participants with a smooth, synchronized, and fair interactive experience. However, existing technologies still face numerous challenges in building a server-side system that can perfectly support these interactive services.

[0003] Current interactive services, particularly those integrating real-time shared media (such as video streaming) and complex interaction logic, often struggle to balance efficient user / participant matching with the immediacy and synchronicity of the interactive experience. Users often face lengthy wait times when seeking interaction partners, which directly dampens their enthusiasm for participation. Once the interaction begins, inconsistent event responses between participating parties, caused by network latency, server-side processing bottlenecks, or client-side differences, can severely undermine the fairness and consistency of the interaction. For example, if the results of one participant's actions are not promptly and accurately reflected by other participants, the results can severely undermine the fairness and consistency of the interaction. More critically, in scenarios involving synchronized playback of shared media (such as videos) or where strict consistency in critical application states (such as changes to important elements in a game scene) is required, significant discrepancies in the shared content, media progress, or application state perceived by each client can severely impact the immersiveness of the shared experience. Furthermore, traditional synchronization mechanisms often struggle with high user concurrency and complex, volatile network conditions, including overall stability, resource efficiency, and the ability to handle various potential anomalies. This makes it difficult to consistently provide high-quality, consistent real-time interactive services. These factors collectively constitute a major obstacle to improving user experience.

[0004] Therefore, how to design a server-side method and system that can achieve efficient and fast user / participant matching, ensure accurate and low-latency synchronization of interactive events, and strictly control the consistency of multi-terminal shared status (such as video playback progress, status of key elements in game scenes, etc.) has become a technical problem that needs to be urgently solved in current real-time interactive services. Summary of the Invention

[0005] The technical problem to be solved by the present invention is that in existing two-person or multi-person interactive services, the random team formation process is inefficient and the matching time is long, the shared media synchronization playback mechanism is not accurate enough, resulting in different user experiences, and the interactive event synchronization mechanism has a high delay that affects the real-time nature of the interaction.

[0006] To achieve the above objectives, the present invention is implemented through the following technical solutions: A first aspect of the present invention provides an efficient matching, video and event synchronization method for an interactive server, the method comprising: S1: The server receives matching requests from at least two client terminals; S2: The server performs matching processing based on the matching request to form at least two of the client terminals into an interactive room. This matching processing is intended to improve matching efficiency and user experience.

[0007] One specific approach is to generate a unique transaction identifier for each matching request, which is used to track the status of the entire matching process. Matching requests, associated with their respective transaction identifiers and user identifiers, are then placed in an asynchronous processing queue. This asynchronous processing mechanism decouples request reception from the actual execution of matching logic, enabling the server to quickly respond to large numbers of concurrent matching requests and reducing user wait time. The server then processes requests from the asynchronous processing queue to identify and combine client terminals that meet pre-defined criteria.

[0008] In order to further improve processing efficiency, the server can periodically and in batches retrieve multiple requests from the asynchronous processing queue for centralized processing.

[0009] At the same time, in order to provide the user with feedback on the matching progress, the method may further include: receiving a matching status polling request initiated by a client terminal using its transaction identifier, and replying with the current matching status associated with the transaction identifier in response to the polling request.

[0010] S3: A real-time communication channel is established between the server and each client terminal in the interactive room. To ensure low latency and reliability for subsequent content sharing and event synchronization, the established real-time communication channel is preferably a WebSocket Secure (WSS) connection. WSS connections provide persistent, two-way communication capabilities and are the foundation for real-time interaction.

[0011] S4: The server receives an interaction event from the first client terminal in the interactive room. These interaction events can be key operations, such as quick response event (QTE) triggering signals, QTE completion signals, or game goal completion signals. The timely synchronization of these events is crucial to ensuring fairness and fun in the interaction.

[0012] In some embodiments, receiving the interaction event involves receiving an initial notification via a first communication protocol (eg, HTTP protocol, which is applicable to scenarios where a client initiates a simple state change).

[0013] S5: The server broadcasts the interaction event or a synchronization event derived therefrom to at least a second client terminal in the interaction room to synchronize the interaction state.

[0014] After receiving the interaction event, the server, acting as a central node, transmits the interaction event, or any subsequent synchronization events, to all other client terminals in the same interactive room via the real-time communication channel (e.g., WSS connection) established in step S3. This centralized broadcast mechanism ensures that all participants receive consistent interaction information.

[0015] If the initial event notification in step S4 adopts the first protocol, the broadcast in this step adopts the second real-time protocol (such as the WSS protocol). The application of this hybrid protocol can be optimized according to communication needs, taking into account the communication efficiency and real-time requirements of different scenarios.

[0016] S6: The server synchronizes the playback progress or key application status of the shared content between the client terminals in the interactive room. Accurate synchronization of shared content or status is the core of enhancing user immersive experience and ensuring interactive fairness.

[0017] The synchronization of the shared content or status can be achieved in response to the interactive event or derived synchronization event broadcast in step S5, or a dedicated video synchronization signal actively broadcast by the server, or a combination thereof. The ultimate goal is to ensure that the basically concurrent shared content presentation or application status between the client terminals is consistent.

[0018] A specific implementation method is that the client terminal dynamically adjusts its local media player state (such as playing, pausing, jumping to a specific frame or time point) or updates its application state based on the timing and content of the broadcast interactive event or derived synchronization event received in step S5, so that the shared content frame or application state associated with the interactive event can be aligned on each client.

[0019] In order to ensure that all users start interacting and watching videos from a unified starting point, this method can also receive a "ready" status signal from the client terminals in the interactive room before synchronizing the video playback progress. After confirming that a predetermined number of client terminals are ready, a unified start synchronization signal is broadcast to all client terminals in the interactive room to initiate synchronized shared content playback or the start of an interactive session.

[0020] Through the above steps, the method of the present invention adopts an efficient matching process of asynchronous queues and transaction identifiers, shortening the user's matching waiting time; by establishing a stable real-time communication channel and using the server as a central hub to receive and instantly broadcast key interactive events, low-latency synchronization of interactive instructions is achieved; and the synchronization of interactive events is closely combined with the control of shared content or status, ensuring the consistency of multi-terminal shared content presentation or application status at key nodes, thereby significantly improving the user experience, fluency and fairness of real-time interactive services.

[0021] A second aspect of the present invention provides an efficient matching, video and event synchronization system for an interactive server, the system comprising: processor; and A memory coupled to the processor, the memory storing computer program instructions, which, when executed by the processor, causes the system to execute any one or more technical solutions of the efficient matching, video and event synchronization method of the interactive server as described in the first aspect of the present invention.

[0022] This system executes instructions in the memory through its internal processor, and can implement all or part of the steps described in the above method, including efficient user / participant matching, secure real-time communication link establishment, precise synchronization of interactive events, and strict control of the playback progress of shared content or key application status, thereby providing powerful server-side support for various real-time interactive services, achieving the purpose of improving user experience and interactive fluency.

[0023] In summary, the present invention includes at least one of the following beneficial technical effects: 1. This invention generates a unique transaction identifier for a matching request and places it in an asynchronous processing queue. Combined with the server-side batch processing mechanism, it can efficiently process a large number of concurrent matching requests, effectively shortening the time users / participants wait for interactive partners and improving the user experience of real-time interactive services.

[0024] 2. This invention leverages the WebSocket secure real-time communication channel established between the server and each client, and the mechanism in which the server acts as a central node to receive interactive events and immediately broadcast them to all other clients in the room. This ensures the rapid transmission of interactive commands and the high consistency of the status of all parties, significantly enhancing the real-time and smoothness of the real-time interactive process.

[0025] 3. The present invention closely links the synchronization of the playback progress of shared content or key application status with key interactive events or dedicated video synchronization signals broadcast by the server. The client adjusts the local media playback or application status based on the received synchronization information, ensuring that different users perceive basically consistent shared content or application status at key moments in the same interactive scenario, greatly enhancing the immersiveness of the interaction and ensuring the fairness of interactions based on shared content or status.

[0026] 4. The server of the present invention uniformly processes and broadcasts "ready" signals, interactive behavior events, and interactive session / task completion events, ensuring that all participants receive consistent status information at key interactive nodes, avoiding interactive logic confusion or experience differences caused by different states of each end.

[0027] 5. By differentiating the communication methods for interactive event reception and synchronous event broadcasting, and centrally processing the synchronization logic on the server side, the present invention reduces unnecessary point-to-point communication and complex state negotiation between clients, simplifies the synchronization model, and improves the overall efficiency and stability of the system in handling synchronization tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 Schematic diagram of the method flow of the present invention; Figure 2 This is a schematic diagram of the video synchronization playback mechanism-interaction timing of the present invention; Figure 3 This is a timing diagram of the random team formation process of the present invention; Figure 4 Schematic diagram of the timing of the interactive event synchronization mechanism of the present invention. DETAILED DESCRIPTION

[0029] In order to make those skilled in the art better understand the technical solution of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of this application can be combined with each other.

[0030] Example 1: like Figure 1 As shown, an embodiment of the present invention provides an efficient matching, video and event synchronization method for an interactive server. For the sake of clarity and to facilitate subsequent detailed description with reference to the accompanying drawings, the method may include the following steps: S100: Execute user / participant matching processing.

[0031] S200: Establish and maintain secure real-time communication between the client and the server.

[0032] S300: Implement synchronization of interactive events.

[0033] S400: Implementing synchronization of multi-terminal shared content playback or key application status.

[0034] It should be emphasized that although the following description uses words such as "player" and "game" for ease of understanding, and some drawings (such as Figure 1 、 Figure 2 ) is illustrated by taking a specific interactive scenario (such as a two-person interactive video) as an example, but the core mechanism and technical solution proposed in the present invention have wide applicability. Efficient matching, secure real-time communication, precise event synchronization, and strict synchronization control of shared content / state are not only applicable to interactive video services, but can also be effectively applied to traditional online multiplayer games, remote collaboration tools, online interactive education platforms and other real-time interactive service scenarios that require high-concurrency user management, low-latency real-time interaction and multi-terminal state consistency. Therefore, the "Game Server" or similar terms described in this embodiment should be understood as a back-end service unit responsible for handling user room management, real-time state synchronization, interactive logic, and real-time communication with the client, and its functions are general and extensible.

[0035] The following is a detailed description of these main stages and the specific operational steps they include.

[0036] In one embodiment of the present invention, in order to achieve fast and effective matching of users / participants in various real-time interactive services, the server adopts an efficient random team formation process. Figure 3 ,This process shows the random team timing provided by the server. The matching processing stage S100 can be divided into the following steps: S101: Receive client matching request and generate transaction identifier like Figure 3 As shown in step 1 of the preceding figure, when a client wishes to join a real-time interactive service, it initiates a match request (e.g., a start match message) to the business server. After receiving this request, the business server generates a globally unique transaction ID for the request in order to uniquely identify and track the entire life cycle of the match request. Figure 3 As shown in step 4, the business server will respond to the client with the generated transactionID (resp transactionID). The client will save this transactionID for subsequent query matching results.

[0037] S102: Asynchronous matching tasks and persistent associated information In order to improve the concurrent processing capability and response speed of the system, the business server does not process the matching logic immediately, but asynchronously processes the matching tasks. Figure 3 As shown in step 2, the business server pushes (lpush) a matching request (expressed as transactionID-uid) containing the transactionID and the user ID (uid) of the requester to an asynchronous task queue. This queue can be managed by a cache system (such as Redis). This design decouples the reception of matching requests from the actual matching processing logic, allowing the business server to quickly respond to new matching requests without being blocked waiting for matching to complete.

[0038] At the same time, if Figure 3 As shown in step 3, the business server will persistently store the mapping between the transactionID and the user ID (userId) in the database (save transID and userId). This facilitates subsequent querying of user information using the transactionID, or linking the user to room information after a successful match. In some implementations, a matching timeout can also be set. If a match fails after the preset timeout, the server can handle the timeout logic and return a timeout status through subsequent client polling.

[0039] S103: Client polls for matching results After initiating a matching request and obtaining a transactionID, the client needs to be informed of the matching progress. Figure 3 As shown in step 5, the client will use its transactionID to periodically send polling requests to the business server to obtain matching results (get match result by TransID). The polling interval can be set according to the specific business scenario and the expected response speed.

[0040] S104: Periodically batch process the matching queue and execute matching logic The business server will periodically or when the queue reaches a certain length, proactively obtain a certain amount of request data to be matched from the asynchronous task queue (queue in the Cache) constructed in step S102. Figure 3 As shown in step 8, the business server sends a command to the cache (for example, Redis's lrange queue 0 10 ), intending to obtain, for example, the first 10 matching data in the queue. The cache then returns the queue data to the business server as shown in step 9.

[0041] After receiving a batch of matching requests, the business server will execute the core matching logic. Figure 3 As shown in step 12 (check match), the server will check whether these requests meet the preset matching conditions. Matching conditions may include but are not limited to: the same selected interaction mode, similar user level or rating, close geographical location, etc. In some implementations, in order to ensure data consistency, transactions are enabled for database (DB) operations when querying and updating matching status. For example, in Figure 3 In steps 10 and 11, the business server first queries the DB (start_trans(query by transID and roomStatus)) based on the transactionID and room status (roomStatus), and the DB returns a response (response) to ensure the atomicity of subsequent operations.

[0042] S105: Create an interactive room and notify the matching results If the business server successfully finds two or more users / participants that can match each other (for example, user A and user B) in the matching logic check of step S104, the matching is successful. Figure 3 As shown in step 13, the business server removes these successfully matched user / participant request keys from the asynchronous task queue (for example, using the Redis lrem command and specifying the key to be removed, lrem queue 1 "removekey", where "removekey" should be understood as the specific transactionID-uid).

[0043] Then, if Figure 3 As shown in step 14, the business server will create a game room (create Room Group Info) for these successfully matched users / participants and assign a unique room ID (roomID). The room information, including the roomID, the transaction IDs of each user / participant associated with the room (such as ownTransaction and matcherTransId, i.e., the transaction IDs of the matching parties), and the opponent information, will be saved. Figure 3 As shown in step 15, this information will be synchronously updated to the database (save RoomId(...)).

[0044] At the same time, in order to facilitate the client to directly connect to the game server (GameServer, here refers to the back-end service unit that handles real-time interaction) that processes the interactive logic, the business server will also obtain and cache an appropriate game server IP address or access address, such as Figure 3 As shown in step 16 (cache gameServer IP).

[0045] Finally, when the client polls the matching result in step S103 (corresponding to Figure 3 In step 6, the business server queries the DB for the matching result (query matchRes by transID) based on the transactionID. The DB returns the matching status (resp match status) in step 7. If the query finds that the room has been successfully created and assigned a roomID, the business server will return the matching result (match Res) containing information such as the roomID, opponent information, and game server IP to the corresponding client. Figure 3 In step 17, it is also indicated that the final match Res (further generated or confirmed by the game server) will eventually be passed to the client.

[0046] Through the above steps S101 to S105, the efficient matching processing stage in the embodiment of the present invention is completed. Its core innovation lies in: by introducing a high-speed cache such as Redis as an asynchronous task queue, it effectively decouples the reception of matching requests from the actual time-consuming matching logic, can calmly handle high-concurrency matching requests, and avoid service congestion. Combined with a globally unique transaction ID (transactionID), it enables full-link tracking and management of each matching request from initiation, queuing, processing to the final result return. The periodic batch pulling and processing mechanism also further optimizes the processing efficiency of the server. These designs jointly ensure that users / participants can quickly match with interactive partners with low latency, significantly improving the user experience.

[0047] After successfully matching users / participants and creating an interactive room in the S100 stage, in order to synchronize shared content and transmit interactive events in real time, the client needs to communicate with the designated game server (GameServer, in Figure 2 Establish and maintain a stable, low-latency, and secure communication link between the room server and the server. Figure 2 The figure shows the interactive sequence of the shared content synchronous playback mechanism, which includes key steps such as connection establishment, authentication, and heartbeat maintenance. Phase S200 can be specifically broken down into the following steps: S201: The client establishes a WSS connection with the game server In step S105, the client obtains the result of successful matching, which includes the assigned roomID and the specified game server address. Figure 2As shown in step 1, the client (e.g., webview1 or webview2, representing the browsers or in-app web views of the two participating clients) uses this information to proactively initiate a WebSocket Secure (WSS) connection request (wss establishes a connection) to the designated game server (roomserver). The WSS protocol adds a TLS / SSL encryption layer to the standard WebSocket protocol, ensuring the confidentiality and integrity of the communication content, which is critical for transmitting sensitive interactive data and user commands.

[0048] When the game server receives the WSS connection request from the client and successfully shakes hands, Figure 2 As shown in step 2, the game server registers the newly established connection instance and its associated information (such as the connection ID and client IP address) with a connection management module (illustrated as connHub set conn in the diagram). The connHub is responsible for centrally managing all active client connections, including connection establishment, maintenance, and closure. This centralized connection management helps the server track client status and efficiently broadcast messages.

[0049] S202: Client authentication and user / participant information registration After the WSS connection is established, it only opens the physical communication link. It also needs to perform application-level identity authentication to confirm the legitimacy of the connecting client and associate it with the specific user / participant identity. Figure 2 As shown in step 3, the client sends an authentication request (wss cs_auth) to the game server through the established WSS connection. This authentication request usually contains information that can prove the user's identity, such as the user ID, a previously obtained session token, or a transaction ID.

[0050] After receiving the authentication request, the game server will verify it. Figure 2 As shown in step 4, the game server registers the user / participant's online status and business-related information through an online user / participant business logic module (illustrated as onlineHub setplayer in the figure). The onlineHub handles business logic related to specific players' game status, room assignments, and more. Decoupling the connection layer's connHub from the business layer's onlineHub improves system maintainability and modularity, allowing connection management and game business logic to evolve independently.

[0051] After successful authentication and completion of user / participant information registration, Figure 2As shown in step 5, the game server will send an authentication success response (sc_auth) to the client, notifying the client that it has successfully connected and initialized and is ready to start the subsequent interaction process.

[0052] S203: Heartbeat detection mechanism WSS is a long connection protocol, but in complex network environments (such as NAT timeout, network fluctuations, etc.), the connection may be disconnected unexpectedly without the two parties being able to detect it in time. In order to maintain the activity of the connection and detect the disconnection in time, this embodiment adopts a heartbeat detection mechanism. Figure 2 As shown in step 6, the client will periodically (for example, every tens of seconds) send a heartbeat request (cs_ping) to the game server through the WSS connection.

[0053] After receiving the cs_ping request, the game server Figure 2 As shown in step 7, the client's last heartbeat time or last active time (updateLastPingTime) will be updated. This timestamp can be used to determine whether the client is still online.

[0054] Then, if Figure 2 As shown in step 8, the game server immediately sends a heartbeat response (sc_pong) to the client. If the client does not receive the sc_pong response within one or more heartbeat cycles, it can determine that the connection is likely disconnected and attempt to reconnect. Similarly, if the server does not receive a cs_ping request from a client for an extended period, it can also assume that the client is offline and execute appropriate cleanup logic (such as removing it from the connHub and onlineHub, notifying other users / participants in the room, etc.).

[0055] Through steps S201 to S203 above, a secure, authenticated, and real-time communication channel maintained via a heartbeat mechanism has been successfully established between the client and the game server. This is an essential foundation for implementing interactive event synchronization (S300) and multi-terminal shared content synchronization or key application state synchronization (S400). The key innovations of this phase include: the use of the WSS protocol to ensure secure and real-time bidirectional communication; the logical decoupling of the connHub (connection layer) and the onlineHub (business layer) enhances system modularity and maintainability; and the heartbeat mechanism ensures the stability of persistent connections and timely detection of abnormal disconnections.

[0056] After establishing a secure real-time communication link between the client and the game server in stage S200, step S300 is to ensure that key events in the two-player or multi-player interaction process can be accurately and low-latency synchronized between all participating clients. This is crucial to ensuring fairness, consistency, and a smooth interactive experience. Figure 2 and Figure 4 , these two pictures show the synchronization mechanism of interactive events from different angles. Figure 4 It focuses more on the synchronization process between users / participants triggered by specific events. Figure 2 This demonstrates how these events are communicated and broadcast between the client and the roomserver (the GameServer instance that executes the room logic in this embodiment) via a hybrid protocol. Stage S300 can be broken down into the synchronous processing of the following typical interactive events: S301: Synchronization of user / participant "ready completed" status Before the interaction begins, it is usually necessary to confirm that all users / participants in the room are ready. Figure 4 As shown in steps 1 and 2, the user / participant A (PlayerA) and the user / participant B (PlayerB) participating in the interaction will send a "ready" signal (ready) to the game server (GameServer). Figure 2 In step 9, it is also indicated that the client (webview2) can send a ready signal to roomserver via HTTP.

[0057] After receiving a ready signal from a user / participant, the game server will wait or check the status of other users / participants in the room. When the game server confirms that all necessary participants in the room (for example, two users / participants in a two-player interaction) have sent ready signals, such as Figure 4 As shown in steps 3 and 4, the game server immediately broadcasts a "both parties are ready" or "interaction is about to begin" synchronization event (broadcast ready, corresponding to a specific sc_ready message type when implemented on the server) to all clients in the room (PlayerA and PlayerB) through the established WSS connection. This broadcast ensures that all users / participants enter the ready-to-start state at the same logical time, laying the foundation for the subsequent synchronous start of shared content (such as video) playback or interaction.

[0058] S302: Synchronization of QTE (Quick Response Event) racing events QTE is a common mechanism in real-time interactive services (such as interactive videos or online games) to enhance participation and test reaction ability. When a QTE is triggered in the game, for example, user / participant A first meets a certain condition or actively triggers a QTE race, such as Figure 4 As shown in step 9, PlayerA will send a QTE race event (qte_race) to GameServer. Figure 2 In step 9, it is also indicated that the client can send the qte_race signal via HTTP.

[0059] After receiving the qte_race event, the game server will immediately broadcast this event (or its derived synchronization events, such as sc_qte_race) to all other relevant users / participants in the room (such as PlayerB) to ensure fairness in the race. Figure 4 As shown in step 10, GameServer broadcasts qte_race to PlayerB (broadcast qte_race). Figure 2 Steps 11 and 12 also show that after receiving events such as qte_race, roomserver broadcasts the corresponding synchronization events (sc_race, sc_qte_race) to webview2 and webview1 via a WSS connection (notify). This instant broadcast allows all users / participants to receive the QTE start instruction almost simultaneously, allowing them to react on a relatively even starting line.

[0060] S303: QTE completes event synchronization When a user / participant responds to a QTE and completes the operation (whether successful or unsuccessful), the result needs to be synchronized with other users / participants. Figure 4 As shown in step 11, assuming PlayerA completes the QTE operation, it will send a QTE completion event (qte_finish) to the GameServer. Figure 2 In step 9, the client may also send a qte_finish signal via HTTP.

[0061] After receiving the qte_finish event, the game server will perform necessary logical judgments (such as determining the QTE result, calculating the time, etc.), and then broadcast this completion event and its results to all users / participants in the room. Figure 4 As shown in steps 12 and 13, GameServer broadcasts the qte_finish event (broadcastqte_finish) to PlayerB and PlayerA. Figure 2 In steps 11 and 12, the roomserver broadcasts sc_qte_finish (a synchronous event indicating the completion of a QTE) to all clients. This allows all users / participants to be informed of the QTE's results in a timely manner and to conduct subsequent interactions accordingly.

[0062] S304: Synchronization of user / participant "goal completion" events In some interactive scenarios, when any user / participant first completes a preset interactive goal, finishes watching a shared content (such as a video), or completes a phased task, this "completion" status also needs to be synchronized to other participants in the room. Figure 4 As shown in step 5, when PlayerA completes the goal, it sends a finish signal to the GameServer. Figure 2 In step 9, the client can also send a finish signal via HTTP.

[0063] After receiving the finish signal from any user / participant, the game server will determine whether to end the current game or enter the next stage according to the interaction rules. Figure 4 As shown in steps 7 and 8, the game server will broadcast this "finish" event (or derived synchronization events, such as sc_finish) to all users / participants in the room (PlayerA and PlayerB). Figure 2 In steps 11 and 12, the roomserver broadcasts the sc_finish event. This can be used to notify other users / participants of the end of the game, display the results, or trigger subsequent processes.

[0064] Through the synchronous processing of various key interactive events from S301 to S304, the present invention ensures that during the real-time interactive process, the interactive status of all participants and the key instructions received remain highly consistent and real-time. The core innovations of this stage are: utilizing the WSS long connection established by S200 for low-latency broadcasting of events; adopting an event-driven design pattern, synchronizing only when key events occur, effectively saving network bandwidth (relative to continuous state synchronization); the server acts as a central hub to uniformly process and distribute events, simplifying the synchronization logic between clients and ensuring the authority and consistency of synchronization. Figure 2As shown in the figure, by combining HTTP (used by clients to initiate simple state change notifications that do not require extremely low latency, such as ready, finish, qte_race, and qte_finish) and WSS (used by servers to broadcast events to all clients with low latency and high reliability), hybrid optimization of the communication protocols is achieved, taking into account both communication efficiency and implementation complexity in different scenarios.

[0065] In all kinds of real-time interactive services, especially those involving shared media (such as video), ensuring that all participating clients experience the same shared content with strict synchronization of playback progress or status is crucial for enhancing user immersion and ensuring fairness. This phase, S400, builds on the communication and event synchronization mechanisms established in the previous phase to ensure consistency in the playback of shared content or key application states across multiple clients at key points in time.

[0066] The synchronization of shared content does not exist in isolation, but is closely linked to the interactive events described in S300. Specifically, the actions of starting, pausing, and aligning key frames of shared content, or the triggering and updating of key application states (such as changes in shared elements in a game scene), are often in response to certain synchronized interactive events or specific control signals issued by the server. Figure 2 The overall interaction logic, event notification and synchronization mechanism (steps 9-12) lay the foundation for shared content / state synchronization.

[0067] Specific methods for achieving strict synchronization of multi-terminal shared content playback or key application status include the following aspects: Synchronous start based on the "ready" signal: As described in S301, once all users / participants have sent a ready signal and the server broadcasts a synchronized sc_ready (or similar start signal), clients can use this as a unified starting point for shared content playback or interaction. Upon receiving this signal, each client simultaneously begins loading and playing the designated shared content (e.g., video) or initializing into a common application scenario. This approach ensures that all users experience the shared content synchronously, starting from frame 0 or a pre-set start frame, or begin interacting from a consistent initial application state.

[0068] Playback / state control and calibration based on key interaction events: During the playback of shared content or the running of interactive applications, the occurrence of certain interactive events is often associated with a specific timeline position of the shared content or a specific stage of the application state. For example: QTE events (qte_race, qte_finish): When the server broadcasts the sc_qte_race event, the event itself may carry the timestamp of the shared content that triggered the QTE or the associated application state identifier. After receiving this event, the client should not only display the QTE interface, but also check whether the local shared content playback progress or application state is aligned with the timestamp. If there is a deviation, the client should actively adjust (fast forward or rewind) to the timestamp to ensure that all users / participants perform QTE operations in the same shared content background or application state. Similarly, the sc_qte_finish event is also used to confirm the end of a QTE window and trigger the shared content (such as video) to continue playing or jumping, or further changes in the application state.

[0069] "Finish" event: When the server broadcasts the sc_finish event, it indicates that a shared content segment has finished viewing, or a task related to the shared content or application state has been completed. The client can use this event to pause the shared content, play an ending animation, jump to the next video segment, or update the application state to reflect the completion of the task.

[0070] Server-side custom synchronization points: In addition to user / participant-triggered events, the server can proactively broadcast specific video synchronization instructions to all clients based on key points in the shared content (such as video scene transitions, the appearance of important information) or key stages in the application logic. These instructions can include target timestamps, playback rate adjustments, or specific application state parameters, forcing all clients to align their playback progress or application state.

[0071] Combination of client-side active calibration and server-side assisted calibration: Client-side active calibration: After receiving various synchronization events related to the shared content timeline or application status broadcast in S300 (such as sc_ready, sc_qte_race, sc_finish, or dedicated video synchronization signals sent by the server), the client will parse the precise shared content timestamp or frame number, or target application state parameters contained in the event. The client's media player or application logic module will then compare this target timestamp / frame number with its current playback progress. If there is a significant difference, the player will automatically perform a seek operation to jump to the specified time point, or the application logic will be updated to the specified state, thereby achieving alignment with the server's instructions or the playback progress or application status of other clients.

[0072] Server-assisted calibration: In scenarios with extremely high synchronization requirements or high network latency, in addition to broadcasting events, the server can also periodically (or when it detects a large deviation in the client's progress) query the client for its current shared content playback progress or application status. Based on the collected information, the server calculates a unified synchronization target time point or status and broadcasts it again to all clients for forced calibration.

[0073] Optimize the delivery of synchronization instructions using hybrid protocols: like Figure 2 As shown, simple state changes or event triggers (ready, finish, qte_race, qte_finish in step 9) can be sent from the client to the server via HTTP requests. This approach is simple for the client to implement and is suitable for scenarios that do not require extremely low latency.

[0074] When the server broadcasts synchronization events or shared content / status control commands to all clients (such as sc_race, sc_finish, and sc_qte_race in steps 11 and 12), it prioritizes the WSS persistent connection established in step 200. This hybrid protocol of WSS real-time broadcast and HTTP simple requests allows for optimized selection based on different communication requirements, ensuring both real-time critical synchronization and convenient operation for some clients.

[0075] Fault tolerance and compensation mechanism: Taking into account factors such as network jitter and client performance differences, absolute frame synchronization or state consistency may be difficult to achieve in real applications. Therefore, fault tolerance mechanisms can be designed, such as allowing for minor playback differences or slight lags in state. At the same time, if a client loses synchronization for a long time due to network problems, the server or client itself should have corresponding compensation mechanisms, such as fast frame tracking, fast state synchronization, or temporarily allowing asynchronous playback without affecting the core experience and resynchronizing at subsequent key nodes.

[0076] Through the combined application of the above mechanisms, embodiments of the present invention can effectively bind and calibrate the playback progress or key application status of each client's shared content (e.g., video) with key interactive events and time nodes in various real-time interactive services, thereby ensuring that all users receive a basically concurrent shared content presentation or consistent application status experience, significantly improving the quality of the synchronization experience and the fairness of interactions based on shared content or status. The core innovation of this stage lies in the close integration of the interactive event synchronization mechanism with the control of shared content or status, utilizing WSS for low-latency synchronization command broadcasting, and optimizing overall communication efficiency through a hybrid protocol, so that shared content or status synchronization is no longer a simple independent playback control, but an organic component integrated into the entire interactive process.

[0077] To more clearly illustrate the overall collaborative process of the interactive server-side efficient matching, video, and event synchronization method provided by the present invention, a simplified working example is provided below, from the user / participant initiating a match to the end of the interaction process. This example integrates the key operations of the aforementioned stages S100 to S400: Phase 1: User / Participant Matching (corresponding to S100) 1. Client request for matching: User / Participant A initiates a "start matching" request to the business server through the client application.

[0078] 2. Transaction processing and enqueuing: The business server generates a unique transactionID for the request and returns it to user / participant A. At the same time, it pushes a matching task containing the transactionID and user / participant A's user ID (uid) into the Redis asynchronous queue and records this mapping relationship in the database.

[0079] 3. Polling and batch matching: User / Participant A's client uses the transactionID to periodically poll for matching results. Meanwhile, the business server periodically pulls batches of matching requests from the Redis queue (e.g., 10 at a time).

[0080] 4. Successful Matchmaking and Room Creation: The business server executes the matching logic and, assuming that User / Participant B, also waiting in the queue, meets the matching criteria, the server then removes the requests from User / Participant A and User / Participant B, creates a new interactive room for them (assigning a roomID), stores the room information, opponent information (User / Participant B's UID), and a designated game server IP address in the cache and database, and returns this roomID and game server IP address to User / Participant A and User / Participant B via polling results.

[0081] Phase 2: Room initialization and communication establishment (corresponding to S200) 5. WSS Connection Establishment: User / Participant A and User / Participant B's clients establish a WebSocket Secure (WSS) persistent connection with the designated game server (roomserver) based on the obtained roomID and game server IP address. The game server's connHub module records these new connections.

[0082] 6. User / Participant Authentication: The clients of User / Participant A and User / Participant B send authentication requests (cs_auth) containing their user credentials over the established WSS connection. Once the game server verifies the user / participant, its onlineHub module registers the user / participant's online status and returns a successful authentication response (sc_auth).

[0083] 7. Heartbeat maintenance: During the entire interaction process, the client and the game server maintain the activity of the WSS connection through periodic cs_ping and sc_pong heartbeat messages.

[0084] Phase 3: Interaction process and event synchronization (corresponding to the combination of S300 and S400) 8. Ready: User / Participant A and User / Participant B each click the "Ready" button on their client. The client sends a "ready" signal to the game server via HTTP or WSS. After receiving the "ready" signal from both parties, the game server broadcasts the "sc_ready" synchronization event via WSS to all users / participants in the room.

[0085] 9. Synchronous start and shared content experience: After receiving sc_ready, all clients simultaneously begin loading and experiencing / playing the specified interactive shared content (such as a video), or initialize into a common application scenario. The start point of shared content playback or the initial application state is aligned based on this synchronization signal.

[0086] 10. QTE Event Triggering and Synchronization: When shared content reaches a preset time point or an application reaches a specific state, a QTE event is triggered. Assuming user / participant A completes the QTE first, their client sends a qte_finish event (containing the QTE result and completion time) to the game server. After verification, the game server immediately broadcasts a sc_qte_finish synchronization event to all players in the room (including user / participant A and user / participant B) via WSS.

[0087] 11. Shared content playback or application state calibration: After receiving sc_qte_finish (or other synchronization events related to the shared content timeline or application state), user / participant B's client will check and calibrate the local shared content playback progress or application state to ensure alignment with the shared content frame or application state when the event occurs.

[0088] 12. Goal Completion and End: When any user / participant (e.g., User / Participant A) finishes experiencing the shared content (e.g., watching a video) or achieves the preset final interaction goal, their client sends a finish signal to the game server. Upon confirmation, the game server broadcasts the sc_finish synchronization event via WSS to all users / participants in the room, notifying them of the end of the interaction.

[0089] 13. Result display and connection disconnection: Each client displays the final result according to the sc_finish event, and then can safely disconnect the WSS connection with the game server.

[0090] This example process connects the core links of the method of the present invention, showing how the various parts work together from matching to the end of interaction to achieve efficient matching, reliable communication, event synchronization, and shared content playback or key application status synchronization.

[0091] Example 2: An embodiment of the present invention further provides an efficient matching, video and event synchronization system for an interactive server, which is intended to execute the efficient matching, video and event synchronization method for an interactive server described in the aforementioned embodiment 1.

[0092] The system includes: Processor: For example, a central processing unit (CPU), graphics processing unit (GPU), application-specific integrated circuit (ASIC), or field-programmable gate array (FPGA). The processor is the core computing unit of the system, responsible for executing computer program instructions stored in memory to control the overall operation of the system and implement the various functions described in this invention.

[0093] Memory: For example, random access memory (RAM), read-only memory (ROM), hard disk drive (HDD), solid-state drive (SSD), or a combination of these types of storage. The memory is used to store the operating system, application programs, and computer program instructions and data required to execute the method of the present invention. Specifically, the memory stores instructions that enable the processor to execute the steps described in Example 1, including S100 (efficient user / participant matching), S200 (secure real-time communication establishment and maintenance), S300 (interactive event synchronization), and S400 (multi-terminal shared content (e.g., video) playback or key application state synchronization).

[0094] Network Interface: For example, an Ethernet card or Wi-Fi module. It enables the system to communicate with other devices (such as client terminals, database servers, cache servers, etc.) through a network (such as the Internet or a local area network) to receive client requests and send synchronization data.

[0095] Input / Output Interface: Used to connect external devices, such as monitors and keyboards for system management and monitoring.

[0096] In specific operation, when the system is running, the computer program instructions stored in the memory are executed by the processor. The execution of these instructions causes the processor and other related hardware components in the system to work together to implement all or part of the technical solutions described in detail in Example 1.

[0097] For example, the processor can implement the following by executing corresponding program module instructions: Receive a matching request from a client terminal, and perform efficient matching processing (such as using asynchronous queues, transaction identifiers, etc.) based on the matching request to form at least two client terminals into an interactive room.

[0098] Establish and maintain a secure real-time communication channel (eg, WSS connection) between the server and each client terminal in the interactive room, including identity authentication and heartbeat detection.

[0099] Receive an interactive event (such as readiness, QTE operation, goal completion, etc.) from a first client terminal in the interactive room, and broadcast the interactive event or a synchronous event derived therefrom to at least a second client terminal in the interactive room in real time to synchronize the interactive state.

[0100] Synchronize the playback progress or key application status of shared content (such as video) between the client terminals in the interactive room to ensure the consistency of the shared content playback or application status at key nodes, such as adjusting its playback progress or status in response to broadcast interactive events or dedicated video synchronization signals.

[0101] Therefore, the system provided by the embodiments of the present invention, through its internal processor executing specific instructions stored in memory, can effectively achieve efficient user / participant matching in various real-time interactive services, secure real-time communication link establishment and maintenance, precise low-latency synchronization of interactive events, and strict control of the playback of multi-end shared content (such as video) or its key application status. This provides solid server-side technical support for building high-quality, user-friendly real-time interactive services for two or more people, thereby achieving the goal of improving the user interaction experience, smoothness, and fairness.

[0102] It should be understood that the above system description is schematic, and the actual system configuration may vary according to specific application requirements and technology selection, but its core function is to implement the method proposed in the present invention.

[0103] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. An efficient matching, video and event synchronization method for an interactive server, characterized in that: The following steps are involved: receiving matching requests from at least two client terminals; performing matching processing based on the matching request to form at least two of the client terminals into an interactive room; establishing a real-time communication channel between the server and each client terminal in the interactive room; receiving an interaction event from a first client terminal in the interaction room; broadcasting the interaction event or a synchronization event derived therefrom to at least a second client terminal in the interaction room to synchronize interaction states; Synchronize the video playback progress between the client terminals in the interactive room, wherein the synchronization of the video playback progress is responsive to the broadcasted interactive event or derived synchronization event, or a dedicated video synchronization signal broadcasted by the server, or a combination thereof, to ensure substantially concurrent video frame presentation between the client terminals.

2. The efficient matching, video and event synchronization method for an interactive server according to claim 1, characterized in that: Performing the matching process includes: A unique transaction identifier is generated for each matching request, the matching requests associated with the respective transaction identifier and user identifier are placed in an asynchronous processing queue, and the requests from the asynchronous processing queue are processed to identify and group client terminals.

3. The efficient matching, video and event synchronization method for an interactive server according to claim 2, characterized in that: Processing requests from the asynchronous processing queue further includes periodically and in batches retrieving a plurality of requests from the asynchronous processing queue for said processing; Furthermore, the method further comprises: A matching status polling request initiated by a client terminal using its transaction identifier is received, and a current matching status associated with the transaction identifier is replied in response to the polling request.

4. The efficient matching, video and event synchronization method for an interactive server according to claim 1, characterized in that: The established real-time communication channel is a WebSocket secure connection.

5. The efficient matching, video and event synchronization method for an interactive server according to claim 1, characterized in that: Before synchronizing the video playback progress, the method further includes: A ready status signal is received from the client terminals in the interactive room, and after confirming that a predetermined number of client terminals are ready, a synchronization signal is broadcast to all client terminals in the interactive room to start synchronized video playback or interactive session start.

6. The efficient matching, video and event synchronization method for an interactive server according to claim 1, characterized in that: Broadcasting the interaction event or its derived synchronous events includes: The server transmits the interactive event or the derived synchronous event to all other client terminals in the same interactive room via the established real-time communication channel.

7. The efficient matching, video and event synchronization method for an interactive server according to claim 1, characterized in that: The received interactive event is a quick response event trigger signal, a quick response event completion signal, or a game goal completion signal.

8. The efficient matching, video and event synchronization method for an interactive server according to claim 1, characterized in that: The synchronization of the video playback progress is achieved in the following ways: The client terminal adjusts its local video playback based on the timing and content of the received broadcast interactive event or derived synchronization event, thereby aligning the video frames associated with the event.

9. The efficient matching, video and event synchronization method for an interactive server according to claim 1, characterized in that: Receiving the interactive event involves receiving an initial notification via a first protocol, and broadcasting the derived synchronization event involves distributing to client terminals using a second real-time protocol.

10. The efficient matching, video and event synchronization system of the interactive server is characterized by: include: processor; as well as A memory coupled to the processor, the memory storing instructions, which, when executed by the processor, cause the system to perform the method according to any one of claims 1 to 9.

Images