WO2018223800A1 - 数据处理方法和装置、存储介质及电子装置 - Google Patents

数据处理方法和装置、存储介质及电子装置 Download PDF

Info

Publication number
WO2018223800A1
WO2018223800A1 PCT/CN2018/086327 CN2018086327W WO2018223800A1 WO 2018223800 A1 WO2018223800 A1 WO 2018223800A1 CN 2018086327 W CN2018086327 W CN 2018086327W WO 2018223800 A1 WO2018223800 A1 WO 2018223800A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
clients
request
client
data packet
Prior art date
Application number
PCT/CN2018/086327
Other languages
English (en)
French (fr)
Inventor
韩伟
艾风
吴佳伟
蔡锦彬
潘兵辉
许路平
杨凯
王伟光
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Publication of WO2018223800A1 publication Critical patent/WO2018223800A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/131—Protocols for games, networked simulations or virtual reality

Definitions

  • the present application relates to the field of data processing, and in particular, to a data processing method and apparatus, a storage medium, and an electronic device.
  • a relatively general broadcast server scheme and a specific game-specific scheme are generally adopted.
  • a server is used to broadcast some of the player's player actions, or certain game state change events, so that clients connected to the server can synchronize the state of the game through these broadcast data.
  • the well-known broadcast service that comes with the client game engine for example, Unity3D provides the "synchronization" function for the specific value of the game object; for example, the Unreal engine also has its own game.
  • Server-side solution with broadcast capabilities In addition to the client-side game engine, there are some more general-purpose broadcast servers, such as Smart Fox Server, a commercial software developed using JAVA. By setting a "server-side variable" concept, multiple clients can read and write. This variable can also receive this variable change notification to achieve the purpose of game state synchronization.
  • a server for broadcasting a video stream such as Adobe Media Server is used as a server for game state broadcast.
  • broadcast servers that come with professional game engines such as Unity/Unreal are generally tied to their client engines. If you want to use other client technologies, you can hardly use their server functions, so versatility is a problem.
  • the broadcast server functions such as Smart Fox Server/Adobe Media Server often only have the function of real-time broadcast, but lack the function of frame synchronous broadcast required by real-time battle games. Performance issues are another major drawback of general-purpose broadcast servers.
  • the above game servers basically do not have the distributed capability, that is, only the function of allowing the game players to concentrate on one server. If a large number of servers are used to form a server cluster, these complex server-side coordination and communication tasks can only be solved by the developers themselves. In addition, most of these servers are commercial software that cannot be modified, and some of them are not source code, so adding cluster functionality is almost impossible.
  • a dedicated broadcast server In addition to being used to broadcast to multiple clients, these servers usually have a large number of control codes for specific game business logic, such as controlling the generation of monsters on the battlefield, the AI of BOSS monsters, the drop of item rewards, etc. Wait.
  • the combat server is also the most frequent failure, the highest probability of occurrence of BUG, because the battle is a continuous online process, so a large amount of state data and network packets are processed in the battle server, which itself is a complex business scenario with multiple users concurrently. Whether it is game logic or the underlying network conditions, this complex real-time system will fail, and this failure is difficult to keep the scene because most of the state is in memory, not on disk, so the battle server Debugging and debugging has always been a problem.
  • the embodiment of the present application provides a data processing method and device, a storage medium, and an electronic device, so as to at least solve the technical problem of high development cost of data processing in the related art.
  • a data processing method includes: a server creates a target scenario for executing a target event, wherein the target event is a real-time battle class event; the server determines a plurality of clients in the target scenario, wherein the plurality of clients are used to execute the target event; the server And periodically broadcasting the first request to the multiple clients, where the first request is used to request the multiple clients to synchronously execute the first event, and the carrying is performed by at least one of the multiple clients for performing the first
  • the first packet of the event, the target event includes the first event.
  • a data processing apparatus applied to a server.
  • the device includes: a creating unit configured to create a target scenario for executing a target event, wherein the target event is a real-time battle class event; and a determining unit configured to determine a plurality of clients in the target scenario, wherein the plurality of clients.
  • the terminal is configured to execute the target event;
  • the broadcast unit is configured to periodically broadcast the first request to the multiple clients, where the first request is used to request the multiple clients to synchronously execute the first event, and is carried by the multiple clients.
  • the first data packet sent by the at least one client for executing the first event, the target event includes the first event.
  • a storage medium having stored therein a computer program, wherein the computer program is configured to perform the steps of the above method embodiments when executed.
  • an electronic device includes a memory, a processor, and a computer program stored on the memory and operable on the processor, wherein the processor executes the above method by using a computer program The steps in the examples.
  • the server creates a target scenario for executing a target event, where the target event is a real-time battle class event; the server determines multiple clients in the target scenario, where multiple clients are used to execute the target
  • the server periodically broadcasts the first request to the plurality of clients, wherein the first request is for requesting the plurality of clients to synchronously execute the first event, and is carried by the at least one of the plurality of clients for Executing a first data packet of the first event, the target event includes a first event, and the first time the broadcast is performed to the multiple clients, so that the multiple clients synchronize to perform the first event, and the frame synchronization broadcast of the universal broadcast server is reached.
  • the purpose of the invention is to achieve a technical effect of reducing the development cost of data processing, thereby solving the technical problem of high development cost of data processing in the related art.
  • FIG. 1 is a schematic diagram of a hardware environment of a data processing method according to an embodiment of the present application
  • FIG. 2 is a flowchart of a data processing method according to an embodiment of the present application.
  • FIG. 3 is a schematic structural diagram of data processing according to an embodiment of the present application.
  • FIG. 4 is a schematic flowchart diagram of a method for simultaneously supporting a frame synchronization and an instant broadcast function according to an embodiment of the present application
  • FIG. 5 is a schematic flowchart diagram of a method for frame synchronization network broadcast according to an embodiment of the present application.
  • FIG. 6 is a schematic flowchart of a method for data redundancy and multiple transmission according to an embodiment of the present application
  • FIG. 7 is a schematic flow chart of a method for disconnecting a disconnection according to an embodiment of the present application.
  • FIG. 8 is a schematic flowchart diagram of a method for consistently buffering a packet according to an embodiment of the present application.
  • FIG. 9 is a structural diagram of a server end according to an embodiment of the present application.
  • FIG. 10 is a schematic diagram of a game room operation flow according to an embodiment of the present application.
  • FIG. 11 is a schematic diagram of a message distribution process according to an embodiment of the present application.
  • FIG. 12 is a schematic diagram of a login process of a client according to an embodiment of the present application.
  • FIG. 13 is a schematic diagram of a starting flow according to an embodiment of the present application.
  • FIG. 14 is a schematic diagram of a frame synchronization process according to an embodiment of the present application.
  • FIG. 15 is a schematic diagram of a broadcast procedure according to an embodiment of the present application.
  • 16 is a schematic diagram of a P2P mode synchronization game according to an embodiment of the present application.
  • 17 is a flowchart of an interface method for parameter synchronization according to an embodiment of the present application.
  • FIG. 18 is a schematic diagram of a data processing apparatus according to an embodiment of the present application.
  • FIG. 19 is a structural block diagram of a terminal according to an embodiment of the present application.
  • an embodiment of a data processing method is provided.
  • FIG. 1 is a schematic diagram of a hardware environment of a data processing method according to an embodiment of the present application.
  • the server 102 is connected to the terminal 104 through a network.
  • the network includes but is not limited to a wide area network, a metropolitan area network, or a local area network.
  • the terminal 104 is not limited to a PC, a mobile phone, a tablet, or the like.
  • the data processing method of the embodiment of the present application may be executed by the server 102, may be performed by the terminal 104, or may be performed by the server 102 and the terminal 104 in common.
  • the data processing method performed by the terminal 104 in the embodiment of the present application may also be performed by a client installed thereon.
  • the above server may be a server for broadcasting the first request.
  • FIG. 2 is a flow chart of a data processing method in accordance with an embodiment of the present application. As shown in FIG. 2, the method may include the following steps:
  • step S202 the server creates a target scene for executing the target event.
  • the target event is a real-time battle-type event
  • the real-time battle-type event executed in the data processing process may be related to the game generated when executing a certain game.
  • the target scenario is a scenario in which the client participating in the execution of the target event is located, and the client participating in the execution of the target event can receive the data broadcast by the server in the target scenario to ensure synchronous processing of the data.
  • the target scene is a virtual room.
  • all clients can send messages, the server system will broadcast this message to the clients in the room, and the target events can be created, destroyed, entered, and exited at runtime during execution.
  • a target scenario for executing the target event can be created.
  • This embodiment achieves management of the target scene by creating a target scene for executing the target event.
  • step S204 the server determines a plurality of clients that are in the target scenario.
  • a plurality of clients are used to execute a target event, and for any target event processing, the participating clients need to be determined, that is, it is necessary to specify which clients need to be in the client. Broadcast data of the same office in the target scene.
  • the server After creating the target scenario for executing the target event, the server determines a plurality of clients that are in the target scenario, and multiple clients can send messages in the target scenario.
  • the multiple clients of this embodiment are not bound to the server.
  • the functions of the server can be common to multiple clients.
  • Other clients can also communicate with the server after entering the target scenario, which improves the generality of the event processing function. Sex.
  • the server After the server determines that there are multiple clients in the target scenario, it is possible to start a synchronized data broadcast of the target event.
  • Step S206 the server periodically broadcasts the first request to the plurality of clients.
  • the first request is used to request multiple clients to synchronously execute the first event, and is carried by the at least one client of the multiple clients for performing the first The first packet of an event, the target event including the first event.
  • Ordinary instant broadcast can be used to implement functions such as channel chat in the game, preparation status notification, and the like, which is not highly synchronous.
  • This embodiment not only broadcasts immediately upon receiving the first request, but also supports frame synchronization.
  • the first request of the embodiment is a request for a server broadcast, and may be sent by at least one client in the client, and carries a first data packet for performing a first event in the target event, where the first data packet may be Includes frame data for controlling the actions performed by the game character.
  • the broadcast function of the frame synchronization can be implemented by using a User Datagram Protocol (UDP).
  • UDP User Datagram Protocol
  • the server After the server determines that the plurality of clients are in the target scenario, the server periodically broadcasts the first request to the plurality of clients for the purpose of broadcasting data, and the data can be broadcast by the timer at a fixed time.
  • Frame synchronization broadcast is a game development function that the server automatically collects the client input group package and then periodically broadcasts the broadcast.
  • the server periodically broadcasts the data packet to drive the real-time network picture synchronization of the client rendering frame, and almost all real-time action online games. , you can use this feature.
  • frame synchronization begins only if one of the following conditions is met: all clients are ready, the server (LockStep Server) times out, and other mechanisms of the server (LockStep Server) satisfy the condition.
  • the frame data is generated by the server (LockStep Server) at a fixed time according to its own timer, and an empty frame is generated even without any user input.
  • the client will automatically check the serial number of each frame synchronization packet. If there is a loss, start the TCP download channel and download the missing frame to the relay server (RelayServer). At this time, the PopFrame() interface will not return the frame data. Until all missing frames are filled, the complete frame data is returned in order.
  • the above two broadcast functions can be provided through two different interfaces.
  • the broadcast mode of the frame synchronization is to periodically broadcast to other clients in the same target scenario regardless of whether the server receives the request sent by the client.
  • the broadcast frequency can be configured. For example, the broadcast frequency is 0.1 second. Up to 0.05 seconds; if any number of clients send requests to the server, the server saves the requests that need to be broadcast, gathers them in the next scheduled broadcast packet, and sends them to all clients.
  • the broadcast channel of this embodiment does not depend on whether the target event starts to be executed, and the data can be sent and received as long as the client successfully logs in. Once the broadcast data arrives at the client's Software Development Kit (SDK), it immediately calls back the user-defined collection function for processing.
  • SDK Software Development Kit
  • the above functions of the embodiment are required to be invoked by the client interface and the server interface when the user is in use.
  • This embodiment can abstract the commonality of the real-time battle-like events, and uniformly complete the functions in the event processing described above.
  • the broadcast capability required for multiple client synchronization processing is a data processing method that can be used for access. It only needs to develop a specific client code, which can quickly realize the processing function of the network real-time battle event and improve the data processing. Efficiency reduces the development cost of data processing.
  • the server since the server periodically broadcasts the first request to the plurality of clients, so that the plurality of clients synchronously execute the first event, the purpose of the frame synchronization broadcast of the universal broadcast server is achieved, thereby reducing the data.
  • the technical effect of the development cost of the processing further solves the technical problem of high development cost of data processing in the related art.
  • step S206 the server periodically broadcasts the first request to the multiple clients, where the server receives the first request sent by the first number of clients, and after receiving the first request, the server is in the first Broadcast the first request to multiple clients at a time.
  • Multiple clients include the first number of clients. After the server determines that there are multiple clients in the target scenario, the server can receive the first request sent by any number of clients in the plurality of clients, and the server saves the requests that need to be broadcast.
  • the server After receiving the first request, the server broadcasts the first request to the plurality of clients at a first time, the first time being separated from the last time the second request is broadcast to the plurality of clients by a first preset time, the second request
  • the method is configured to request a plurality of clients to synchronously execute the second event, and carry a second data packet sent by at least one of the plurality of clients for executing the second event, where the target event includes the second event.
  • the server periodically broadcasts the clients in the same target scenario. After receiving the first request sent by the first number of clients, the server saves the first requests and broadcasts the first request to the plurality of clients at the first time.
  • the server aggregates the first request sent by the first number of clients in the periodically broadcasted data packet, and broadcasts the first request to the multiple clients at the first time.
  • the first time is a time when the time arrives, and is separated from the time when the last time the server broadcasts the second request to the plurality of clients, the first preset time may be set, for example, the first preset time is 0.1.
  • the second request is similar to the first request, and is configured to request the plurality of clients to synchronously execute the second event, and carries the second event sent by the at least one of the plurality of clients for executing the second event.
  • the second data packet, the target event includes a second event.
  • step S206 the server periodically broadcasts the first request to the multiple clients, including: when the first time arrives, and the request sent by any multiple clients is not received, The client broadcasts the first request carrying the empty frame.
  • the server When the server periodically broadcasts the first request to multiple clients, the server broadcasts the received request to the client in the same target scenario at a predetermined time interval regardless of whether the server receives the request sent by the client.
  • the server still broadcasts the first request carrying the empty frame to the plurality of clients, that is, even if the client does not have any input, A null frame is generated to implement the broadcast function of the frame synchronization of the general server.
  • step S206 the server periodically broadcasts the first request to the multiple clients, where the server separately acquires N data packets carried in the first N times of requests broadcasted to the multiple clients; A first request carrying N data packets and a first data packet is broadcast to a plurality of clients.
  • the server obtains N data packets carried in the first N times of requests broadcasted to multiple clients, and N times correspond to N data packets one by one, and N is a natural number greater than or equal to 1.
  • the network In the process of data processing of battle events, for example, in the process of real-time synchronous action game development, the network will have problems such as delay fluctuation, occasional packet loss, and short disconnection, so it is necessary to optimize the weak network environment.
  • each packet is actually retransmitted multiple times, that is, each broadcast packet carries the contents of the packet that should be sent several times before.
  • the server After determining the plurality of clients in the target scenario, the server respectively obtains N data packets carried in the first N times of requests broadcasted to the plurality of clients, and N times are the number of retransmissions of the data packets, and N data.
  • One-to-one correspondence which is a natural number greater than or equal to 1, can be set.
  • the server After acquiring the N data packets carried in the request for broadcasting to the plurality of clients in the first N times, the server periodically broadcasts the first request carrying the N data packets and the first data packet to the plurality of clients, thereby realizing A strategy that uses redundant multiple transmissions to reduce the impact of packet loss.
  • the embodiment achieves the purpose of periodically broadcasting the first request to multiple clients by using the foregoing method, and specifically optimizes the problem of delay fluctuation and occasional packet loss occurring in the network, without requiring too much attention of the developer, thereby realizing A strategy that uses redundant multiple transmissions to reduce the impact of packet loss.
  • step S206 after the server periodically broadcasts the first request to the plurality of clients, the first data packet is recorded; the server periodically broadcasts the third request to the plurality of clients; and records the third data packet.
  • the first data packet is recorded, so that the first data packet is saved, so that if the client has a disconnection reconnection, the client may send the unreceived again.
  • the first packet After periodically broadcasting the first request to the plurality of clients, the first data packet is recorded, so that the first data packet is saved, so that if the client has a disconnection reconnection, the client may send the unreceived again. The first packet.
  • the server periodically broadcasts a third request to the multiple clients, where the third request is used to request the multiple clients to synchronously execute the third event, and carries the third one sent by the at least one client of the multiple clients for executing the third request.
  • the third packet of the event, the target event includes the third event.
  • the server After recording the first data packet, the server receives a third request sent by at least one of the plurality of clients, and when the timed time arrives, broadcasts a third request to the multiple clients, where the third request carries a third data packet sent by at least one of the plurality of clients for executing the third event, the target event including the third event,
  • the server After the server periodically broadcasts the third request to the plurality of clients, the third data packet is recorded, so that the third data packet is saved, so that the client may send the unreceived to the client again if the client has a disconnection reconnection.
  • the third packet to.
  • This embodiment achieves the purpose of recording all the data packets broadcasted in the target scenario on the server side by the above method, so as to not receive the data packets during the disconnection of the client.
  • the method further includes: the first client in the plurality of clients loses the connection, and the third is recorded in the step S206.
  • the server sends the first data packet and the third data packet to the first client, and the first client of the plurality of clients loses the connection, including: the first client of the plurality of clients The network where the terminal is located is disconnected; or the first client of the multiple clients exits the event execution process.
  • the network experiences delay fluctuations, occasional packet loss, and short disconnection. Since the packet is lost after the disconnection, that is, after the first request is broadcast to the plurality of clients at a timing, the first client in the plurality of clients loses the connection, and after recording the third packet.
  • the first client of the server does not receive the first data packet and the third data packet during the process of losing the connection. Since the first data packet and the second data packet have been recorded on the server side, the first data packet and the third data packet are sent to the first client, so that the client can quickly obtain the unreceived data packet, thereby avoiding the client losing the packet. The situation of the package appears to improve the efficiency of data processing.
  • the data packets are identified by a serial number, and the serial number of each data packet has a preset order. After the client reconnects, it will automatically download the unreceived and recorded packets from the serial number of the last broadcast packet after the last disconnection.
  • the first client of the multiple clients loses the connection including two cases.
  • the first case because the network is disconnected, in this case, the first client can invoke the interface to log in again; the second case
  • the first client For the first client to exit the event execution process, for example, the game player exits the game process, at this time, the address information, the key value information, the frame number of the current frame, and the like in the target scene are lost, and the client needs to log in again, and from the first One frame (PopFrame) starts synchronizing data.
  • PopFrame One frame
  • the server after the server periodically broadcasts the first request to the multiple clients, the first client in the multiple clients loses the connection and re-establishes after recording the third data packet.
  • the server receives a customized fourth request sent by the client; the server responds to the fourth request and sends the first data packet or the third data packet to the first client.
  • the server receives the fourth request sent by the client.
  • the fourth request is for requesting to acquire the first data packet or the third data packet, and the first client does not receive the first data packet and the third data packet in the process of losing the connection.
  • the server After the server periodically broadcasts the first request to the plurality of clients, the first client of the plurality of clients loses the connection, and in the case that the connection is re-established after the third data packet is recorded, the client can customize the selection. Received packets that have been recorded by the server are received. Receiving a customized fourth request sent by the client, where the fourth request is used to request to acquire a first data packet or a third data packet that is customized by the client.
  • the client can also customize to download from the serial number corresponding to a certain data packet, which is applicable to the case where the game itself has a snapshot of the implementation state, that is, it is suitable for timing the state in the game recorded by the client.
  • the lost data can be downloaded from the state snapshot by restoring the most recent state snapshot, wherein the state snapshot is determined based on the sequence number of the broadcasted packet.
  • This function can also be used to replay the video of the game. Since only the operation data of the game is recorded, the game video is much smaller than the file saved by the video recording.
  • the server responds to the fourth request, and sends the first data packet or the third data packet to the first client, and after the server receives the fourth request sent by the client, sends the first data to the first client after responding to the fourth request.
  • Package or third packet
  • first data packet and the third data packet are not limited to the server only broadcasting the first data packet and the second data packet, as long as the data packet carried by the server periodically broadcasts the request to the client is in the present application.
  • no more examples are given here.
  • the client quickly obtains the unreceived data packet by using the foregoing method, thereby avoiding the situation that the client loses the packet and improving the data processing efficiency.
  • the server recording the first data packet includes: when the first data packet is not a null frame, the server records the first data packet; and the server recording the third data packet includes: the third data packet In the case of not being empty, the server records the third packet.
  • the server After the server periodically broadcasts the first request to the plurality of clients, the first data packet is recorded, and when the first data packet is not a null frame, the first data packet is recorded, that is, when the first data packet is an empty frame. When it is not, it will not be kept in the server.
  • the third data packet After periodically broadcasting the third request to the plurality of clients, if the third data packet is not a null frame, the third data packet is recorded, that is, when the third data packet is a null frame, Reserved in the server. Therefore, the client that is disconnected by the disconnection does not acquire the packet of the empty frame again.
  • the first data packet is identified by the first serial number
  • the third data packet is identified by the second serial number, where the first serial number and the second serial number are consecutive.
  • each data packet broadcast by the server is identified by a serial number, that is, each data packet has a unique serial number, and the serial number of each data packet can be continuously incremented as the transmission time increases, so that when there is a packet loss
  • the client can determine the missing packet based on the missing serialization in multiple consecutive sequence numbers.
  • the first data packet is identified by a first serial number
  • the third data packet is a data packet sent after the first data packet is sent, and is identified by a second serial number, and the first serial number and the second serial number are consecutive.
  • step S206 the server periodically broadcasts the first request to the multiple clients, where the server periodically sends the first data packet to the buffer of each client, where the first data packet is scheduled by each The client processes it.
  • a buffer of a certain size is established at the client, and the server periodically sends the first data packet to the buffer area of each client, and the client does not process the first data packet immediately after receiving the first data packet, but first puts the buffer into the buffer, and then periodically The first data packet in the buffer is processed by the client code, so that the data packet obtained by the client is relatively stable in a certain period of time.
  • the client does not immediately notify the game logic code, but first puts the buffer into the buffer, and then periodically notifies the game client code of the data packet of the buffer.
  • the client code will process the resulting packets steadily over a certain period of time. Although this will increase the delay of the overall network packet, it can keep the arrival speed of all network packets consistent, thus forming a stable operation feel for the user and improving the user experience.
  • the method further includes: in the case that the first data packet is invalid, the server prohibits sending the first data.
  • the client of the package performs the target event, and/or the server records information indicating that the first data packet is illegal.
  • the server is required to verify the validity of the data packet. When the first request is broadcast to a plurality of clients at a timing, it is verified whether the first data packet is legal.
  • online games generally face the threat of plug-in and cracking. In the real-time battle of the game, it is often necessary to verify the validity of the broadcast data packets.
  • the server prohibits the client that sends the first data packet from executing the target event, and/or the server records information indicating that the first data packet is illegal.
  • the server prohibits the client that sends the first data packet from executing the target event, for example, in the game processing event, when a certain client is found
  • the server can prevent the cheating client from executing game events in the target scene, that is, "canceling" the cheat client into the game.
  • a complete cheat record of the cheating client can be obtained for further processing of the client later, for example, further punishing and preventing the cheating client according to the complete cheating record of the cheating client.
  • the server-side interface of the embodiment has all the functions of the client interface, and additionally increases the management capability of the target scenario, and reduces the development cost of the data processing.
  • the server, whether the first data packet is valid includes: the server, by using the first server, whether the first data packet is legal.
  • the server broadcasts the first data packet to the first server, and broadcasts all the data broadcasted to the client to the first server.
  • the first server may be a game server (GameServer) set by the developer, so that the game server is The data packets received by all clients can be grasped in real time, thereby performing any authentication authentication that needs to be acquired.
  • the game server is used to calculate the server process of the main game logic in a general network game.
  • the server After the server broadcasts the first data packet to the first server, it is verified by the first server whether the first data packet is legal.
  • the game server finds that a client is cheating, the developer can not only "kick out” the problematic client to the game, but also get a complete cheat record for further punishment and prevention in the future.
  • This embodiment achieves the purpose of verifying whether the first data packet is legal by the above method.
  • the method further includes: setting, by using the first server, the first server to verify that the first data packet is invalid by the first server The operation information is set; the preset operation information is broadcasted by the first server to the client other than the client that sends the first data packet to the plurality of clients.
  • the preset operation information is set by the first server, and the preset operation information is used to indicate that the clients of the plurality of clients are not the same as the client that sends the first data packet.
  • the client performs a preset operation.
  • the preset operation information is used to indicate that the client other than the client that sends the first data packet performs a preset operation, for example, dropping the loot in the game.
  • the first server After the preset operation information is set by the first server, the first server sends the preset operation information to the client other than the client that sends the first data packet to the plurality of clients, for example, through the broadcast interface of the server.
  • the data information of the dropped loot is sent to the client existing in the target scene.
  • This embodiment implements the broadcast of information in the target scenario by the above method.
  • the server creates a target scenario for executing the target event, including: the server creates a target scenario by calling a preset interface; and/or the server sends the target scenario to the multiple clients by using a preset interface.
  • the information of the target scene includes at least one of the following: address information of the target scene; key value information of the target scene; and a uniform resource locator of the target scene.
  • the preset interface is invoked, and the preset interface may be an interface of the LockStep Service, and the target scenario is created through the interface.
  • the information of the target scene is sent to the multiple clients through the preset interface, where the information of the target scene includes the address information of the target scene, the key value information of the target scene, and the target. Uniform resource locators for the scene, etc.
  • a 5V5 battle is initiated.
  • the GameSvr creates a PVP room by calling the interface of the LockStep Service.
  • the LockStep Service returns the member ID, RoomKey and the room Url, and returns the information to the client through the GameSvr. end.
  • step S206 the server periodically broadcasts the first request to the multiple clients, including: the server acquires operation information of each client; combines operation information of each client into data frames; The client broadcasts the first request carrying the data frame.
  • the server After determining each client in the target scenario, the server obtains operation information of each client, that is, collects action information of each client.
  • the server After obtaining the operation information of each client, the server combines the operation information of each client into data frames, that is, constitutes a complete frame content.
  • the server After combining the operational information of each client into a data frame, the server periodically broadcasts a first request carrying the data frame to the plurality of clients to broadcast the data frame to the client corresponding to other game players in the target scene.
  • the embodiment achieves the purpose of periodically broadcasting a first request to multiple clients by using the foregoing method.
  • the broadcast broadcasts the first request to multiple clients, so that multiple clients simultaneously execute the first event, and the universal broadcast server is reached.
  • the purpose of frame synchronization broadcast is achieved.
  • step S202 the server creates a target scenario for executing the target event, including: acquiring, by the server, scenario information of the multiple second servers; receiving the scenario creation request, and according to the scenario information of the multiple second servers Determining a target server for creating a target scenario; the server sends a create instruction to the target server; after the target server receives the create instruction, the target scenario is created by the target server.
  • the server acquires scene information of the plurality of second servers, and the scenario information of each second server includes information for indicating a scene that each second server allows to create and a scene that has been created.
  • the server When creating a target scenario for executing a target event, the server acquires scenario information of a plurality of second servers, which may be room servers (RoomSvr), and each second server periodically reports to all scenario management servers (RoomMng) And reporting the scenario information of each second server, where the scenario information is used to indicate information about a scenario that each second server allows to create and a scenario that has been created.
  • RoomSvr periodically reports its own information to all RoomMng, including how many rooms are supported, how many rooms have been created, etc., where RoomSvr has specific information about the room, and all the frame data generated in the room, the process crashes ( After Crash), the information of the corresponding room will be lost, and the service side can recreate the room.
  • RoomMng It can be expanded in parallel and can be dynamically expanded according to business needs.
  • the main function of RoomMng is to collect the status of each RommSvr and manage the creation of the room.
  • the specific room information is In Tcaplus, instead of in RoomMng's memory, the process can be restarted immediately after the process crashes, and the information can be pulled to the RoomSvr, the service can be quickly restored, the parallel expansion can be performed, the memory and CPU consumption will not be too large, and two nodes are deployed in one cluster. Just fine.
  • the server receives the scenario creation request, and determines a target server for creating the target scenario according to the scenario information of the multiple second servers, where the scenario creation request is used to request to create the target scenario.
  • the server After obtaining the scenario information of the multiple second servers, the server receives a scenario creation request for requesting to create a target scenario, where the scenario creation request is randomly located on a RoomMng, and when the RoomMng receives the request, it integrates all the current seconds.
  • the load condition of the server select a target server to send a command to create a room.
  • the server sends a create instruction to the target server, which is used to instruct the target server to create a target scene.
  • the server After determining the target server for creating the target scenario based on the scenario information of the plurality of second servers, the server sends a creation instruction to the target server to instruct the target server to create the target scenario.
  • the server After the target server receives the creation instruction, the server sends a creation instruction to the target server, creates a target scenario through the target server, and assigns each client in the target scenario a random key, which can be used for subsequent client-to-server Information is encrypted or decrypted when the information is transmitted.
  • the embodiment achieves the purpose of creating a target scenario for executing a target event by using the foregoing method, thereby determining a plurality of clients in the target scenario; periodically broadcasting the first request to multiple clients to synchronize multiple clients.
  • the first event is executed, and the purpose of the frame synchronization broadcast of the general broadcast server is achieved, thereby achieving the technical effect of reducing the development cost of the data processing.
  • the method further includes one of: after the target event is executed by the multiple clients, the server closes the target scenario; After the client exits the target scenario, the server closes the target scenario; when the client does not communicate with multiple clients within the second preset time, the server closes the target scenario; when the target scenario is created for more than the third preset time, the server is shut down.
  • Target scenario after the server creates a target scenario for executing the target event in step S202, the method further includes one of: after the target event is executed by the multiple clients, the server closes the target scenario; After the client exits the target scenario, the server closes the target scenario; when the client does not communicate with multiple clients within the second preset time, the server closes the target scenario; when the target scenario is created for more than the third preset time, the server is shut down.
  • Target scenario after the server creates a target scenario for executing the target event in step S202, the method further includes one of: after the target event is executed by the multiple clients, the server closes the target scenario; After the client exit
  • the server may close the created target scenario, including: after the target event is executed by multiple clients, the server closes the target scenario, optionally, the game server (GameSvr) actively destroys The room, including the normal end of the game, or the game found that the client cheats and abnormally closed, the message path can be GameSvr->RoomMng->Tcaplus; after multiple clients exit the target scene, close the target scene, optionally, RoomSvr When all the clients exit the room and close the room, this is the normal PVP battle ending process.
  • the message path can be RoomSvr->RoomMng->Tcaplus; when there is no communication with multiple clients within the second preset time. Close the target scene.
  • the RoomSvr closes the room because there is no message communication for a certain period of time in the room. This is mainly to prevent the PVP from ending normally, but the GameSvr and the client do not actively call to close the room.
  • the message path can be RoomSvr. ->RoomMng->Tcaplus; the time to create the target scene exceeds the third preset time The target scene is closed.
  • the automatic scanning tool scans the room established in the Tcaplus table more than 2 days ago and closes it. This is to prevent the room information from being lost due to the restart of the RoomSvr.
  • the message path is CleanTool->Tcaplus. Among them, Tcaplus is a storage system independently developed by IEG R&D department, and CleanTool is a tool for clearing data.
  • the method further includes: the server verifying the login information of the multiple clients; and logging in to the at least one client. In the case that the information verification fails, the server sends the verification failure information; when the verification of the login information of the plurality of clients is successful, the server sets the data sent by the multiple clients to the empty frame.
  • the server After determining the plurality of clients in the target scenario, the server verifies the login information of the plurality of clients, and checks the key value (MemberKey) of each client.
  • the server After verifying the login information of multiple clients, if the verification of the login information of at least one client fails, the server sends a verification failure information, that is, if the verification of the login information of the client fails, an error is returned. information.
  • the server After verifying the login information of multiple clients, if the login information of multiple clients is successfully verified, the server sets the data sent by multiple clients to an empty frame, which can be sent by multiple clients.
  • the current frame number (FrameId) of the data is marked as 0, and the data with FrameId of 0 is not retained, that is, data with a FrameId of 0 is not received after the client disconnects.
  • the login of the office will verify the MemberKey, and if it fails, an error message is returned.
  • the server peer status is marked as Login.
  • the server forwards the client's input, but the FrameId is marked as 0, and the data with FrameId 0 is not retained in LockStepSvr, that is, the disconnection is reconnected.
  • the client will not receive data with a FrameId of 0.
  • This embodiment implements the login of the client in the target scenario by the above method.
  • step S206 the server periodically broadcasts the first request to the multiple clients, where the server receives the fifth request sent by the multiple clients, responds to the fifth request, and allows timing to be sent to multiple clients. Broadcast the first request.
  • the server receives a fifth request sent by a plurality of clients, and the fifth request is used to request to start executing the target event.
  • the server When periodically broadcasting the first request to a plurality of clients, the server receives a fifth request sent by the plurality of clients, the fifth request being used to request to start executing the target event.
  • the timing of the start of the game is that the server receives the fifth request sent by all the clients to start the formal forwarding, and the fifth request may be a BattleStart.
  • the server After receiving the fifth request sent by the multiple clients, the server responds to the fifth request, at which time the current frame number FrameId is marked as 1, indicating that the frame synchronization is officially started, and allowing the timing to broadcast the first request to the plurality of clients.
  • This embodiment achieves the purpose of starting to periodically broadcast a first request to a plurality of clients by the above method.
  • the server allows the timing to broadcast the first request to the multiple clients, including: in the case that the fifth request sent by the multiple clients is not all received, the server allows timing at the third preset time. Broadcast the first request to multiple clients.
  • the server When the server allows the first request to be broadcast to multiple clients, when the fifth request sent by multiple clients is not received, that is, only the fifth request sent by some clients is received, the server triggers. a timeout mechanism for allowing the first request to be broadcast to a plurality of clients at a third preset time. For example, 10 seconds after receiving the fifth request sent by the first client, the frame synchronization process is also started, and the third The preset time can be set by the server.
  • the method further includes: the server receiving the sixth request sent by the multiple clients, where the sixth request is used for The request ends the execution of the target event; the server responds to the sixth request and closes the target scenario to cause the plurality of clients to end the execution of the target event.
  • the server receives a sixth request sent by a plurality of clients, and the sixth request is used to request to end the execution of the target event.
  • the execution of the target event by the plurality of clients may be ended.
  • the server receives a sixth request sent by multiple clients, and the sixth request is used to request to end the preset time.
  • the client invokes the end interface (Stop interface), at which time the client's input is discarded.
  • the server After receiving the sixth request sent by the plurality of clients, the server responds to the sixth request and closes the target scenario to cause the plurality of clients to end the execution of the target event, and the target scenario enters a destruction state.
  • This embodiment achieves the purpose of ending the execution of the target event by a plurality of clients by the above method.
  • step S206 the server periodically broadcasts the first request to the multiple clients, where: the server acquires a frame synchronization parameter; acquires a data packet sent by multiple clients according to the frame synchronization parameter; and the server pairs the multiple clients.
  • the data packet sent by the terminal is packaged to obtain the first data packet.
  • the server obtains a frame synchronization parameter, and the frame synchronization parameter is used to indicate the number of frames transmitted per second.
  • the frame synchronization parameter is passed in when the target scene is created. It is used to indicate the number of frames transmitted per second. For example, the frame synchronization parameter is 15 frames/s, which is used to indicate 15 frames per second.
  • the server After obtaining the frame synchronization parameter, acquires the data packet sent by multiple clients according to the frame synchronization parameter, and may start the first frame of the outgoing frame, and perform an auto-incrementing policy on the current FrameId to obtain the data packet sent by multiple clients.
  • the server performs packet processing on the data packets sent by the multiple clients to obtain a first data packet.
  • the first data packet includes at least: identifier information of each client, a current frame number, and a data packet sent by each client.
  • the server After obtaining the data packets sent by the multiple clients according to the frame synchronization parameter, the server performs packet processing on the data packets sent by the multiple clients to obtain the first data packet, which can be between n frames and n+1 frames.
  • the client's input data packet is packaged to obtain the first data packet.
  • the server After packet processing is performed on the data packets sent by the multiple clients, after the first data packet is obtained, the server broadcasts the first data packet to the multiple clients, that is, broadcasts the first data packet to all clients in the target scenario. .
  • the first data packet sent by the server of the embodiment to the client includes: identifier information of each client, a current frame number, and a data packet sent by each client, where the identifier information of each client is used.
  • each client sends a packet that is the input information of the client.
  • This embodiment achieves the purpose of periodically broadcasting a first request to multiple clients by the above method, and achieves the technical effect of frame synchronization.
  • the server broadcasting the first data packet to the multiple clients includes: when the first data packet exceeds the preset transmission amount, the server broadcasts the preset to the multiple clients in the current frame.
  • the preset transmission amount of the embodiment may be a Maximum Transmission Unit (MTU), which is a maximum datagram size that can pass on a certain layer of the communication protocol, and the preset transmission amount may be in bytes. unit.
  • MTU Maximum Transmission Unit
  • the server packages to obtain m*k messages, and if the MTU is exceeded, the message will be exceeded. Put it in the next frame to package. Between n frames and n+1 frames, if m clients do not input, the current FrameId is incremented, and all clients are broadcast simultaneously, but no message is packed.
  • step S206 the server periodically broadcasts the first request to the multiple clients, including: receiving, by the at least one of the plurality of clients, a first sequence number of the first data packet and at least If the third serial number of the data packet received by the client is not continuous, the server receives the seventh request sent by the at least one client; and responds to the seventh request, and sends the data identified by the fourth serial number to the at least one client. package.
  • the server receives at least one client if the first sequence number of the first data packet received by the at least one client of the plurality of clients is not continuous with the third sequence number of the data packet received by the at least one client before And a seventh request, where the seventh request is used to request to acquire a data packet identified by the fourth serial number, where the first serial number is used to identify the first data packet, and the third serial number is used to identify the at least one client received before The data packet, the fourth serial number is located between the first serial number and the third serial number, and is continuous with the first serial number and the third serial number.
  • the server and client interfaces cooperate to ensure that the serial number of the data packet is contiguous. If the sequence number of the packet is not continuous, the request is actively sent to obtain the lost frame (LostFrame).
  • the server After receiving the seventh request sent by the at least one client, the server responds to the seventh request, and sends a data packet identified by the fourth serial number to the at least one client, thereby implementing a packet loss compensation policy.
  • the frame synchronization defaults to 2 frames of information, and the maximum redundant 3 frames of information can be adaptively switched according to the user network environment.
  • This embodiment achieves the purpose of periodically broadcasting a first request to a plurality of clients by the above method.
  • the data processing method is invoked through a server interface and a client interface.
  • the client of the embodiment accesses the server RoomSvr for creating the target scenario through the Tconnd, and the client datagram protocol UDP transparent transmission mode is used between the client and the Tconnd, and the data encryption and decryption is not performed on the Tconnd, and the encryption and decryption work is performed.
  • Tconnd is a network access component process independently developed by the IEG R&D department, which can convert concurrent network connection (TCP/UDP) data into message queue requests to intranet processes for decoupling network connection processing and
  • the service logic is the access layer, stateless, and the process restart does not affect the service function.
  • RoomMng's main function is to collect the status of each RommSvr, manage the creation of the room, the specific room information is stored in Tcaplus, not in the memory of RoomMng. After the process Crash, it can immediately restart and pull information to the RoomSvr to quickly restore the service.
  • RoomSvr has the specific information of the room and all the frame data generated in the room. After the process Crash, the information of the corresponding room will be lost. Because the PVP will not last for a long time, the impact will be small, so the business will focus on Just create a new room. Tconnd is the access layer, stateless, and the process restart does not affect the service function.
  • This embodiment can be used universally for real-time synchronized games that require a frame synchronization mechanism, as well as for the simplest online chat room applications.
  • the game application in addition to supporting frame synchronization, it also supports the synchronization implementation method of partial state synchronization, which is very flexible to use.
  • This embodiment can make a game development team that does not have the ability or does not want to write a frame synchronization mechanism by itself, and can easily develop a game by using the technique of frame synchronization. And using this technology, does not require authorization on the source code, just access the SDK of the system.
  • the target event is a game event
  • the target scenario is a room.
  • FIG. 3 is a schematic structural diagram of data processing according to an embodiment of the present application.
  • the data processing includes a relay management process (RelayMgr), a relay server (RelaySvr), an access component process (Tconnd), a client (Client), a game server (GameSvr), and a service interface (LockStep Service Api).
  • the relay management process and the service interface interact to realize the creation of the room and the closing of the room
  • the relay server transmits the data frame to the server interface
  • the data frame is transmitted between the access component and the client, and the client and the game server Use game logic.
  • a general game developer needs to access the universal real-time synchronization server system described in this embodiment on both sides of the client and the server, which is simply referred to as a server system.
  • the server system primarily provides the broadcast capabilities required for game synchronization. It is described in detail below:
  • the participating players need to be determined. That is, it is necessary to clarify which clients need to broadcast data of the same office. Clients who need to work together are called into a virtual room. In this room, all clients can send messages, and the server system will broadcast this message to all other clients in this room. Because the game needs to create, destroy, enter, and exit these virtual rooms at runtime, the server system needs to provide these capabilities. In the game logic, once a battle that requires real-time synchronization is turned on, the above functions of the server system can be invoked to create a room, and then the client enters the room to start the synchronized data broadcast of the game.
  • Broadcast data is the most important function of the system, but this embodiment not only broadcasts immediately upon receipt of a request packet, but also supports broadcast in a frame synchronization manner. These two broadcast features are available through two different interfaces.
  • the broadcast mode of the frame synchronization is that the server broadcasts the timeout (frequency configurable, generally 0.1 second to 0.05 second) to other clients in the same room regardless of whether the client receives the request; if any number of clients When the request is sent, the server will save the requests that need to be broadcast, and then collect the packets in the next scheduled broadcast, and finally send them to all clients.
  • the ordinary instant broadcast can be used to perform functions such as channel chat in the game, preparation status notification, and the like, and the synchronization is not required; the frame synchronization can be simultaneously implemented as the synchronization of the action in the game.
  • FIG. 4 is a schematic flowchart diagram of a method for simultaneously supporting a frame synchronization and an instant broadcast function according to an embodiment of the present application.
  • the client 1 (1P Client) broadcasts input data (Input) to the relay server (Relay Server), and the relay server broadcasts the input data of the client 1 to the client 2 (2P Client).
  • the relay server broadcasts the input data of the client 1 to the client 2 (2P Client).
  • FIG. 5 is a schematic flowchart diagram of a method for frame synchronization network broadcast according to an embodiment of the present application.
  • the client 1P sends data Opr1 and Opr4 to the server
  • the client 2P sends data Opr2 and Opr3 to the server
  • the server sends the data Opr1 and Opr4 sent by the client 1P and the data Opr1 sent by the client 2P.
  • Empty Empty
  • the network will have problems such as delayed fluctuations, occasional packet loss, and short disconnection.
  • This embodiment is optimized for the above problems without requiring too much attention from the developer.
  • FIG. 6 is a schematic flowchart diagram of a method for data redundancy and multiple transmission according to an embodiment of the present application.
  • the embodiment includes a client 1 (Client1), a client 2 (Client2), and a client 3 (ClientN).
  • the client 1 inputs data Input1, Input2, and Input3 to a cloud server (Lock Step Cloud).
  • the client 2 inputs the data Input1, Input2, and the client 3 inputs the data Input1, and then returns the first frame data Frame1, Frame2, Frame3, where Frame1 includes the data Client1.Input1, Client2.Input1, Client3.empty; Frame2 includes the data.
  • Frame3 includes the data Client1.Input3, Client2.Input2, Client3.Input1.
  • each packet will actually be retransmitted 2 to 3 times, that is, each packet will be carried twice before.
  • the number of retransmissions can be set to solve the packet loss problem during packet loss data transmission.
  • the system will record all the packets broadcasted by the whole game on the server side, and the client is disconnected. After reconnecting, it will automatically re-download all recorded packets starting from the serial number of the last broadcast packet of the last disconnection, and then re-accelerate the entire game.
  • the client can also customize to download from a serial number. This applies to the fact that the game itself has a snapshot of the state, that is, the state of the game is recorded on the client, so that the latest state snapshot can be restored. The lost broadcast data is then downloaded from this state snapshot (as determined by the broadcast packet serial number). This function can also be used to replay the video of the game. Because of the recorded operation data of the game, this game video is much smaller than the file saved by the video recording.
  • FIG. 7 is a schematic flow chart of a method for disconnection of a disconnection according to an embodiment of the present application.
  • the client 1 due to the weak network environment, multiple packets of the Relay Server are not processed by the client 1 (1P Client), so the client 1 needs fast forwarding processing, and the client 1 is disconnected again. After the connection, it will automatically download all the recorded data packets from the serial number of the last broadcast packet of the last disconnection, and then re-accelerate the entire game, and finally display the same result as Client 2 (2P Client). .
  • a buffer of a certain size can be established at the client, and the game logic code is not immediately notified after receiving the network broadcast packet, but is first put into the buffer, and then the data packet of the buffer is periodically notified to the game client code.
  • FIG. 8 is a schematic flowchart diagram of a method for consistently buffering a packet according to an embodiment of the present application.
  • the game logic (Game Logic) in the client sends an operation to the relay server (Realy Server), and after receiving the operation, the relay server broadcasts the received operation, and the client receives the operation.
  • the buffer is first placed in the buffer (Cache), and after accumulating a fixed number, the data packet of the buffer is periodically notified to the game client code.
  • the data packets obtained by the client code will be relatively stable for a certain period of time. Although this will increase the overall network packet delay, it will allow all network packets to reach the same speed, allowing the player to form a stable operating feel.
  • the real-time battle process of the game often requires verification by the server for legality.
  • all the data broadcasted to the client is broadcast to the game server (GameServer) set by the developer, so that the game server can grasp all the data packets received by the client in real time, thereby performing any self.
  • GameServer GameServer
  • the authentication verification you want.
  • the game server finds that a client cheats, the developer can not only "kick out" the problematic client to the game, but also get a complete cheat record for further punishment and prevention of the cheating client in the future.
  • the game server can also use this function to perform server-side operations for sensitive operations. For example, you need to drop the loot in the game. This operation can be done by the game server and then sent to all clients using the broadcast interface. Dropped spoils data information.
  • the game server interface of this embodiment actually has all the functions of the client interface, and additionally adds room management capabilities.
  • FIG. 9 is a structural diagram of a server side according to an embodiment of the present application.
  • the server segment architecture diagram includes a storage system (Tcaplus), a room management service (RoomMng), a room server (RoomSvr), an access component process (Tconnd), a client (Client), and an access development kit. (LockStepFrame), Game Server (GameSvr), Service Interface (Apollo Service Api).
  • the data transmission protocol between the room management service and the server interface is a transmission control protocol, and the data transmission protocol with the game server is also a hypertext transfer protocol.
  • RoomMng Room Management Service, which provides the GameSvr game server with the ability to create rooms, destroy rooms, and query rooms.
  • RoomSvr Provides the function of collecting frame data, framing, and broadcast frame data for players of the same Room (one PVP, that is, an interactive competitive game formed by players using each other to attack game resources).
  • a RoomSvr can serve multiple rooms at the same time.
  • Tconnd As the access layer of RoomSvr, it provides UDP access for client players.
  • LockStepFrame The client-oriented access SDK provides interfaces for establishing connections, sending frame data, and closing connections.
  • Tcaplus RoomMng will save the created room information to Tcaplus.
  • GameSvr lobby for example, 5V5 is launched.
  • GameSvr creates a PVP room by calling the interface of LockStep Service.
  • LockStep Service returns the member ID, RoomKey and room Url, and the room management service GameSvr returns this information to Clients, each game client will be connected to the same PVP RoomSvr.
  • the frame synchronization forwarding logic that is, collect the actions of each client to form a complete frame content broadcast to the client. Other players in the game.
  • FIG. 10 is a schematic diagram of a game room operation flow according to an embodiment of the present application.
  • the client logs in to the game and initiates a competition request.
  • the game server GameSvr
  • the room management service (RoomMng) transmits the information of the created room to the room server (RoomSvr).
  • the room management service returns room information
  • the room management service transmits the room information to the game server
  • the client obtains the room information from the game server.
  • the client logs in to the PVP room, and the client officially synchronizes the message before the game.
  • the room server broadcasts data of other clients
  • the client notifies the room server that preparation is completed
  • the room server waits for the client. All preparations are completed, notifying all clients that the battle begins.
  • the client sends frame data to the room server, and the room server waits for the player's frame data, framing, and broadcasts the frame data to all clients.
  • the client requests a frame from the room server, and the room server sends the frame data to the client.
  • the client exits the room.
  • Table 1 is a storage data structure table of an embodiment of the present application.
  • the field name is member_info, the type is blob (2564); the field creation timestamp field name is create_time, the type is uint64; the last update timestamp field name is last_update_time, and the type is uint64.
  • RoomSvr One room corresponds to one PVP game, the room exists in RoomSvr, and one RoomSvr can support multiple rooms. RoomSvr periodically reports its information to all RoomMng, including how many rooms are supported, how many rooms have been created, and so on.
  • GameSvr initiates a command to create a room
  • the request will randomly drop on a RoomMng.
  • RoomMng receives the request, it will synthesize the current load of all RoomSvr and select a RoomSvr to send a command to create a room.
  • RoomSvr After RoomSvr receives the command to create a room, it will create a room and assign a random key to each member of the room. The Key will be used for subsequent client-to-RoomSvr message encryption and decryption.
  • the RoomID is int64 type.
  • the first 32 bits are the RoomSvr process ID, the last 32 bits are the in-process increment sequence, and the RoomKey is a randomly generated string with a length of 32.
  • RoomMng After receiving the response from RoomSvr to successfully create a room, RoomMng will write the information of this room to TCAPLUS.
  • the information includes RoomID, service ID, number of members, process ID of RoomSvr, access address, and key of each member.
  • the ways to destroy the room include the following four types:
  • GameSvr actively destroys the room, this includes the normal end of the game, or the game is found to be cheated by the player and is abnormally closed.
  • the message path is GameSvr->RoomMng->Tcaplus;
  • RoomSvr receives all the messages from the client exiting the room, and closes the room. This is the normal PVP battle ending process.
  • the message path is RoomSvr->RoomMng->Tcaplus;
  • RoomSvr shuts down the room because there is no message communication for a certain period of time in the room. This is mainly to prevent PVP from ending normally, but GameSvr and the client do not actively call to close the room.
  • the message path is RoomSvr->RoomMng->Tcaplus;
  • the automatic scanning tool scans the room created more than 2 days before the Tcaplus table and closes it. This is to prevent the room information from being lost due to the restart of the RoomSvr.
  • the message path is CleanTool->Tcaplus.
  • FIG. 11 is a schematic diagram of a message distribution process according to an embodiment of the present application.
  • the client 1 logs in to the room server (RoomSvr), and the room server login checks the MemberKey (Verify). If the verification fails, the response is incorrect. information.
  • Client 2 logs in to the room server.
  • the status of the LockStepSvr game is marked as Login.
  • LockStepSvr will forward the client Input, but the FrameId is marked as 0, and the data with FrameId 0 will not be retained in LockStepSvr, that is, the disconnection is reconnected.
  • the client will not receive data with a FrameId of 0.
  • Client 1 synchronizes messages before the official battle, such as loading progress.
  • the timing of the start of the game is that LockStepSvr receives the BattleStart request from all clients before starting the formal match forwarding.
  • start sending a BattleStart request (SttleStart) to the server (SVR).
  • the FrameId is marked as 1, indicating that the frame synchronization has officially started.
  • LockStepSvr will trigger a timeout mechanism, such as 10 seconds after receiving the first BattleStart request (specific time GameSvr specified), Start the frame synchronization process, at this time the LockStepSvr state is LockStep.
  • the LockStepSvr state is LockStep.
  • the room server waits until it receives a START command from all clients and begins to notify the client (BattleStart Notify).
  • Client 1 and client 2 input a frame (Frame Input) to the room server, and the room server framing to obtain buffered frame data.
  • the room server sends complete frame data (Complete Frame Data) to client 1 and client 2.
  • Client 1 and Client 2 exit the LogOut room server after receiving the room server sent by the room server.
  • the game reconnection is divided into two cases.
  • the first case is that the player calls the Login interface to log in again because the network is disconnected, and the RequestFrame (LastFrameId) is called to obtain the lost. Frame data.
  • the second case the player process exits, and the information such as room URL, MemberKey, and FrameId is lost.
  • GameSvr needs to go to the RoomSvr query to obtain relevant information and then re-login, and synchronize data from the first frame.
  • the client calls the Stop interface.
  • LockStep indicates that the link is in the Stop state.
  • the Input input of the client will be discarded, and after receiving the Stop request from most clients, the room enters the destruction state.
  • GameSvr will pass the frame synchronization parameter when creating the room, for example, 15 frames/s.
  • LockStepSvr will increment the FrameId from the first frame.
  • the information sent by the server to the client mainly includes three parts, an ObjectId (a unique representation of the client), a FrameId (current frame number), and an input information of the client.
  • LockStepSvr will pack m*k messages. If the MTU is exceeded, some messages will be placed in the next frame for packing.
  • LockStepSvr will increment the FrameId and broadcast all clients, but not package any messages.
  • the LockStepSvr and the client API cooperate to ensure that the message received by the user must be consecutive frame numbers. If the client API finds that the frame number is not continuous, it will actively request the lost frame (LostFrame), and the user does not need to care about the frame loss problem.
  • the frame synchronization defaults to 2 frames of information, and the maximum redundant 3 frames of information are adaptively switched according to the user network environment.
  • the client accesses the RoomSvr through Tconnd, and the Udp transparent transmission mode is adopted between the client and the Tconnd.
  • the data encryption and decryption is not performed on the Tconnd, and the encryption and decryption work is completed by the RommSvr.
  • RoomMng The main function of RoomMng is to collect the status of each RommSvr and manage the creation of the room.
  • the specific room information is stored in Tcaplus, not in the memory of RoomMng. After the process Crash, it can be restarted immediately and pull information to the RoomSvr to quickly restore the service.
  • RoomSvr has the specific information of the room and all the frame data generated in the room. After the process Crash, the information of the corresponding room will be lost. Because the PVP will not last for a long time, the impact will be small, so the business will focus on Just create a new room.
  • Tconnd is the access layer, stateless, and the process restart does not affect the service function.
  • RoomMng can be expanded in parallel, memory and CPU consumption will not be too large, deploy two nodes in a cluster.
  • RoomSvr can be expanded in parallel and dynamically expanded according to business needs.
  • FIG. 12 is a schematic diagram of a login process of a client according to an embodiment of the present application.
  • the Game Client needs to create a room for the battle game
  • the Game Server sends a request to the server system (LockStep Server) to request to create a room
  • the server system returns a response request to the game server to create a room.
  • the game client sends a request to enter the room to the game server
  • the game server sends a result of the request to the game client to enter the room
  • the game client logs in to the client system, and connects to the server system, if the server system requires the client
  • the end system re-logs in
  • the client system sends a re-login request to the server system
  • the server system returns the result of responding to the re-login request (it is noted that the sequence numbers 0 to 9 in FIG. 12 are used to indicate the sequence of execution of each step).
  • FIG. 13 is a schematic diagram of a starting flow according to an embodiment of the present application.
  • Game Client1 sends a broadcast (SendBroadcast) message to the client system (LockStep Client), and the client system sends a broadcast message to the server system (LockStep Server), and the server system sends the message to the client system.
  • the client system sends a response message of the broadcast message to the client 1.
  • the game client N sends a broadcast message to the server system, the server system responds to the broadcast message, and sends a response message of the broadcast message to the game client N.
  • the game client N receives the first frame (PopFrame)
  • the game can be considered to have started.
  • the game can also access the HasStarted attribute to determine whether the game has started (it is noted that the numbers 1 to 3, 1', and 2' in FIG. 13 are used to indicate the order of execution of each step).
  • FIG. 14 is a schematic diagram of a frame synchronization procedure according to an embodiment of the present application.
  • the game client 1 sends input data to the client system
  • the client system sends input data to the server system
  • the server system inputs the data group frame
  • the game client receives the first frame (PopFrame) data.
  • the game client N sends input data to the server system, and the server system returns the first frame data to the client N.
  • the numbers 1 to 5, 1', and 5' in FIG. 14 are used to indicate the sequence of execution of each step. order).
  • the frame synchronization of this embodiment will only begin if one of the following conditions is met: all players are Ready; the LockStep Server times out; other mechanisms that satisfy LockStep Server.
  • the frame data is generated by LockStep Server at its fixed time according to its own timer, and an empty frame is generated even without any user input.
  • the client will automatically check the sequence number of each frame synchronization packet. If there is packet loss, start the TCP download channel and download the missing frame to RelayServer. At this time, the PopFrame() interface will not return the frame data until all. The missing frame is filled in to return the complete frame data in order.
  • FIG. 15 is a schematic diagram of a broadcast procedure according to an embodiment of the present application.
  • the game client 1 transmits broadcast information (SendBroadcast)
  • the client system transmits broadcast information to the server system
  • the server system returns broadcast data to the client system
  • the client system transmits broadcast data to the game client 1.
  • the game client 2 sends a broadcast message to the server system, and the server system transmits the broadcast data to the game client 2 (it is to be noted that the numbers 1 to 4, 1' and 4' in Fig. 15 are used to indicate the order of execution of each step. ).
  • the broadcast channel of this embodiment does not depend on whether the game is started or not, and can transmit and receive data as long as the login is successful. Once the broadcast data reaches the client's software development kit, it will immediately call back the user-defined collection function for processing.
  • the data processing method of this embodiment is versatile and can be used for a real-time synchronous game requiring a frame synchronization mechanism, and can also be used for the simplest online chat room application.
  • the game application in addition to supporting frame synchronization, it also supports the synchronization implementation method of partial state synchronization, which is very flexible to use.
  • This embodiment allows a game development team that does not have the ability or does not want to write a frame synchronization mechanism by itself, and can easily develop its own game using the technique of frame synchronization. And using this technology, does not require authorization on the source code, just access the SDK of the system.
  • this embodiment integrates many functions required for real-time synchronous game play, for example, variable redundant UDP packets to reduce the experience degradation caused by packet loss; automatic download of missing frames and UDP redundancy
  • the two designs which undertake the recovery of the network package for packet loss and disconnection, make it unnecessary for the developer to develop the relevant network operation code by itself, which greatly reduces the development cost;
  • the network synchronization service can be separated from the general game server cluster to form a cluster that can be deployed and operated separately.
  • the server system is completely clustered, that is, it can expand its carrying capacity indefinitely, and also has the clusters of runtime expansion, dynamic disaster tolerance, and load balancing.
  • the inherent benefits of the service don't require game developers to do any development work. This allows the game project to have a strong carrying capacity simply by accessing the cloud service of the system, which is very convenient for the operation of the game project.
  • multiple game projects can share the same set of network synchronization clusters, which can minimize the waste of hardware resources.
  • FIG. 16 is a schematic diagram of a P2P mode synchronization game according to an embodiment of the present application.
  • a plurality of mobile phone clients enter a room, send game data to the room management server, the room management server sends synchronized game data to the game server, and the game server verifies the legality of the synchronized game data, wherein the plurality of mobile phone clients The transfer between the P2P transfers synchronized game data.
  • the interface adopted is not a function of "receiving” and “sending”, but is realized by the form of "status parameter" synchronization.
  • FIG. 17 is a flowchart of an interface method for parameter synchronization according to an embodiment of the present application.
  • the game state synchronization system and the plurality of mobile phone clients wherein the plurality of mobile phone clients include the parameter A.
  • the mobile client sends a parameter modification event to the game state synchronization system through the parameter A.
  • the game state synchronization system receives the parameter modification event through the parameter A, the parameters of other clients in the plurality of mobile phone clients, and the mobile phone client that sends the modification parameter event.
  • the parameters appear to be synchronous. In fact, this scheme simply broadcasts the modification event of the state parameter and then wraps the event.
  • the bottom layer of this scheme still has the same interface of "receiving" and "sending" as the system.
  • the server system of this embodiment needs to complete a series of tasks such as a data broadcast function, a real-time synchronized game state, an optimized network delay packet loss experience, a player disconnection reconnection capability, and a replay of a game of the game.
  • a data broadcast function such as a data broadcast function, a real-time synchronized game state, an optimized network delay packet loss experience, a player disconnection reconnection capability, and a replay of a game of the game.
  • the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, by hardware, but in many cases, the former is A better implementation.
  • the technical solution of the present application which is essential or contributes to the related art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk, CD-ROM).
  • the instructions include a number of instructions for causing a terminal device (which may be a cell phone, a computer, a server, or a network device, etc.) to perform the methods described in various embodiments of the present application.
  • FIG. 18 is a schematic diagram of a data processing apparatus according to an embodiment of the present application. As shown in FIG. 18, the apparatus may include: a creating unit 10, a determining unit 20, and a broadcasting unit 30.
  • the creating unit 10 is configured to create a target scenario for executing a target event, wherein the target event is a real-time battle class event.
  • the determining unit 20 is configured to determine a plurality of clients in the target scenario, wherein the plurality of clients are configured to execute the target event.
  • the broadcast unit 30 is configured to periodically broadcast the first request to the multiple clients, where the first request is used to request the multiple clients to synchronously execute the first event, and the carrying is carried by at least one of the multiple clients.
  • the creating unit 10 in this embodiment may be configured to perform step S202 in the embodiment of the present application.
  • the determining unit 20 in the embodiment may be configured to perform step S204 in the embodiment of the present application.
  • the broadcast unit 30 may be configured to perform step S206 in the embodiment of the present application.
  • the embodiment realizes the technology of reducing the development cost of the data processing by broadcasting the first request to the plurality of clients at a timing to enable the plurality of clients to synchronously execute the first event, thereby achieving the purpose of the frame synchronization broadcast of the general broadcast server, thereby realizing the development cost of the data processing.
  • the effect further solves the technical problem of high development cost of data processing in the related art.
  • the foregoing units are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the above Embodiment 1.
  • the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware. Among them, the hardware environment includes the network environment.
  • an electronic device for implementing the above data processing method is further provided for application to a server or a terminal.
  • FIG. 19 is a structural block diagram of a terminal according to an embodiment of the present application.
  • the terminal may include one or more (only one shown in the figure) processor 191, memory 193, and transmission device 195.
  • the terminal may further include an input/output device 197. .
  • the memory 193 can be used to store a software program and a module, such as a data processing method and a program instruction/module corresponding to the device in the embodiment of the present application.
  • the processor 191 executes each of the software programs and modules stored in the memory 193.
  • a functional application and data processing, that is, the above data processing method is implemented.
  • Memory 193 can include high speed random access memory and can also include non-volatile memory such as one or more magnetic storage devices, flash memory, or other non-volatile solid state memory.
  • memory 193 can further include memory remotely located relative to processor 191, which can be connected to the terminal over a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
  • the transmission device 195 described above is for receiving or transmitting data via a network, and can also be used for data transmission between the processor 191 and the memory 193. Specific examples of the above network may include a wired network and a wireless network.
  • the transmission device 195 includes a Network Interface Controller (NIC) that can be connected to other network devices and routers via a network cable to communicate with the Internet or a local area network.
  • the transmission device 195 is a Radio Frequency (RF) module for communicating with the Internet wirelessly.
  • NIC Network Interface Controller
  • RF Radio Frequency
  • the memory 193 is used to store an application.
  • the processor 191 can call the application stored in the memory 193 through the transmission device 195 to perform the following steps:
  • the target event includes the first event.
  • the processor 191 is further configured to: receive a first request sent by a first number of clients, where the plurality of clients includes a first number of clients; after receiving the first request, at a first time Broadcasting the first request to the plurality of clients, wherein the first time is separated from the last time the second request is broadcast to the plurality of clients by a first preset time, and the second request is used to request the plurality of clients to perform the second synchronization An event, and carrying a second data packet sent by at least one of the plurality of clients for executing the second event, the target event comprising the second event.
  • the processor 191 is further configured to perform the following steps: when the first time arrives, and the request sent by any of the multiple clients is not received, the first request to carry the null frame is broadcast to the plurality of clients.
  • the processor 191 is further configured to: obtain N data packets carried in the first N times of the broadcast to the plurality of clients, where N times are corresponding to N data packets, and N is greater than or equal to a natural number of 1; periodically broadcasting a first request carrying N data packets and a first data packet to a plurality of clients.
  • the processor 191 is further configured to: record the first data packet after periodically broadcasting the first request to the multiple clients; periodically broadcast the third request to the multiple clients, where the third request is used for the request.
  • the client concurrently executes the third event, and carries a third data packet sent by at least one of the plurality of clients for executing the third event, the target event includes a third event; and the third data packet is recorded.
  • the processor 191 is further configured to: after the first request is broadcast to the plurality of clients, the first client of the plurality of clients loses the connection, and the connection is re-established after the third data packet is recorded.
  • the first data packet and the third data packet are sent to the first client, where the first client does not receive the first data packet and the third data packet in the process of losing the connection, in the multiple clients
  • the first client losing the connection includes: a network disconnection where the first client of the plurality of clients is located; or the first client of the plurality of clients exits the event execution process.
  • the processor 191 is further configured to: after the first request is broadcast to the plurality of clients, the first client of the plurality of clients loses the connection, and the connection is re-established after the third data packet is recorded.
  • the fourth request sent by the client is received, where the fourth request is used to request to acquire the first data packet or the third data packet, and the first client does not receive the first data packet and the first process in the process of losing the connection.
  • Three data packets responding to the fourth request and sending the first data packet or the third data packet to the first client.
  • the processor 191 is further configured to: perform verification on whether the first data packet is legal when the first request is broadcast to the plurality of clients, and to prohibit sending the first data when the first data packet is invalid.
  • the client of the package performs the target event and/or records information indicating that the first data packet is not legitimate.
  • the processor 191 is further configured to perform the steps of: broadcasting the first data packet to the first server; and verifying, by the first server, whether the first data packet is legal.
  • the processor 191 is further configured to: acquire operation information of each client; combine operation information of each client into a data frame; and periodically broadcast a first request carrying the data frame to the plurality of clients.
  • the processor 191 is further configured to: obtain scene information of multiple second servers, where the scenario information of each second server includes a scenario for indicating that each second server allows creation and a scenario that has been created. Receiving a scenario creation request, and determining a target server for creating a target scenario according to scenario information of the plurality of second servers, wherein the scenario creation request is used to request to create a target scenario; and sending a creation instruction to the target server, where the instruction is created Used to instruct the target server to create a target scenario; after the target server receives the creation instruction, create a target scenario through the target server.
  • the processor 191 is further configured to: perform verification on the login information of the multiple clients after determining the plurality of clients in the target scenario; in the case that the login information verification of the at least one client fails, The verification failure information is sent; when the verification of the login information of the multiple clients is successful, the data sent by the multiple clients is set to an empty frame.
  • the processor 191 is further configured to: receive a fifth request sent by multiple clients, where the fifth request is used to request to start executing the target event; respond to the fifth request, and allow timing to broadcast to the plurality of clients. A request.
  • the processor 191 is further configured to perform the step of: broadcasting the first request to the plurality of clients at a third preset time permitting timing if the fifth request sent by the multiple clients is not all received.
  • a solution for data processing is provided. Since the first request is periodically broadcast to a plurality of clients, so that the plurality of clients simultaneously execute the first event, the purpose of the frame synchronization broadcast of the general broadcast server is achieved, thereby achieving the technical effect of reducing the development cost of the data processing, and further The technical problem of high development cost of data processing in the related art is solved.
  • the terminal can be a smart phone (such as an Android mobile phone, an iOS mobile phone, etc.), a tablet computer, a palm computer, and a mobile Internet device (MID). Terminal equipment such as PAD.
  • Fig. 19 does not limit the structure of the above electronic device.
  • the terminal may also include more or less components (such as a network interface, display device, etc.) than shown in FIG. 19, or have a different configuration than that shown in FIG.
  • a storage medium is also provided.
  • the above storage medium may be used in a computer program that executes a data processing method.
  • the foregoing storage medium may be located on at least one of the plurality of network devices in the network shown in the foregoing embodiment.
  • the storage medium is arranged to store a computer program for performing the following steps:
  • the target event includes the first event.
  • the storage medium is further configured to store a computer program for performing the steps of: receiving a first request sent by a first number of clients, wherein the plurality of clients comprises a first number of clients; After the first request, the first request is broadcast to the plurality of clients at a first time, wherein the first time is separated from the last time the second request is broadcast to the plurality of clients by a first preset time, and the second request is used for The requesting the plurality of clients to synchronously execute the second event, and carrying the second data packet sent by the at least one of the plurality of clients for executing the second event, the target event includes the second event.
  • the storage medium is further configured to store a computer program for performing the following steps: broadcasting the carrier to the plurality of clients when the first time arrives and the request sent by any of the plurality of clients is not received The first request for an empty frame.
  • the storage medium is further configured to store a computer program for performing the following steps: respectively acquiring N data packets carried in the first N times of requests broadcasted to the plurality of clients, wherein N times and N data One-to-one correspondence, N is a natural number greater than or equal to 1; periodically broadcasts a first request carrying N data packets and a first data packet to a plurality of clients.
  • the storage medium is further configured to store a computer program for performing the following steps: recording the first data packet after periodically broadcasting the first request to the plurality of clients; periodically broadcasting the third request to the plurality of clients, The third request is used to request multiple clients to synchronously execute the third event, and carries a third data packet sent by at least one of the multiple clients for executing the third event, where the target event includes Three events; record the third packet.
  • the storage medium is further configured to store a computer program for performing the following steps: after periodically broadcasting the first request to the plurality of clients, the first client of the plurality of clients loses the connection and is recording In the case that the connection is re-established after the third data packet, the first data packet and the third data packet are sent to the first client, where the first client does not receive the first data packet and the third during the process of losing the connection.
  • the data packet, the first client of the plurality of clients losing the connection comprises: a network disconnection where the first client of the plurality of clients is located; or the first client of the plurality of clients exits the event execution process.
  • the storage medium is further configured to store a computer program for performing the following steps: after periodically broadcasting the first request to the plurality of clients, the first client of the plurality of clients loses the connection and is recording In the case that the connection is re-established after the third data packet, the fourth request sent by the client is received, where the fourth request is used to request to acquire the first data packet or the third data packet, and the first client is in the process of losing the connection.
  • the first data packet and the third data packet are not received; in response to the fourth request, the first data packet or the third data packet is sent to the first client.
  • the storage medium is further configured to store a computer program for performing the steps of: verifying whether the first data packet is legal when the first request is broadcast to the plurality of clients at a time; verifying that the first data packet is illegal In case, the client that sends the first data packet is prohibited from executing the target event, and/or the information indicating that the first data packet is illegal is recorded.
  • the storage medium is further arranged to store a computer program for performing the steps of: broadcasting the first data packet to the first server; verifying, by the first server, whether the first data packet is legitimate.
  • the storage medium is further configured to store a computer program for performing the steps of: creating a target scene by calling a preset interface; and/or transmitting information of the target scene to the plurality of clients through a preset interface, wherein the target
  • the information of the scene includes at least one of the following: address information of the target scene; key value information of the target scene; and a uniform resource locator of the target scene.
  • the storage medium is further configured to store a computer program for performing the following steps: acquiring operation information of each client; combining operation information of each client into data frames; and periodically broadcasting data carried by the plurality of clients The first request for the frame.
  • the storage medium is further configured to store a computer program for performing the following steps: acquiring scene information of the plurality of second servers, wherein the scene information of each second server includes indicating for each second server to allow The created scenario and the information of the created scenario; receiving the scenario creation request, and determining a target server for creating the target scenario according to the scenario information of the plurality of second servers, wherein the scenario creation request is used to request to create the target scenario; The server sends a create instruction, wherein the create instruction is used to instruct the target server to create the target scenario; after the target server receives the create instruction, the target scenario is created by the target server.
  • the storage medium is further configured to store a computer program for performing one of the following steps: after determining a plurality of clients in the target scenario, verifying login information of the plurality of clients; at least one If the verification of the login information of the client fails, the verification failure information is sent; when the verification of the login information of the multiple clients is successful, the data sent by the multiple clients is set to an empty frame.
  • the storage medium is further configured to store a computer program for performing one of the steps of: receiving a fifth request sent by the plurality of clients, wherein the fifth request is for requesting to start executing the target event; responding to the fifth request And allow timing to broadcast the first request to multiple clients.
  • the storage medium is further configured to store a computer program for performing one of the following steps: in the case that the fifth request sent by the plurality of clients is not all received, the timing is allowed to be increased at the third preset time The client broadcasts the first request.
  • the foregoing storage medium may include, but not limited to, a USB flash drive, a Read-Only Memory (ROM), a Random Access Memory (RAM), a mobile hard disk, and a magnetic memory.
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • mobile hard disk a magnetic memory.
  • magnetic memory a variety of media that can store computer programs, such as a disc or an optical disc.
  • the integrated unit in the above embodiment if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in the above-described computer readable storage medium.
  • the technical solution of the present application may be embodied in the form of a software product, or the whole or part of the technical solution, which is stored in the storage medium, including
  • the instructions are used to cause one or more computer devices (which may be a personal computer, server or network device, etc.) to perform all or part of the steps of the methods described in the various embodiments of the present application.
  • the disclosed client may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • multiple units or components may be combined or may be Integrate into another system, or some features can be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, unit or module, and may be electrical or otherwise.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.
  • the server creates a target scenario for executing a target event, where the target event is a real-time battle class event; the server determines multiple clients in the target scenario, where multiple clients are used to execute the target
  • the server periodically broadcasts the first request to the plurality of clients, wherein the first request is for requesting the plurality of clients to synchronously execute the first event, and is carried by the at least one of the plurality of clients for Executing a first data packet of the first event, the target event includes a first event, and the first time the broadcast is performed to the multiple clients, so that the multiple clients synchronize to perform the first event, and the frame synchronization broadcast of the universal broadcast server is reached.
  • the purpose is to achieve a technical effect of reducing the development cost of data processing.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请公开了一种数据处理方法和装置、存储介质及电子装置。其中，该方法包括：服务器创建用于执行目标事件的目标场景，其中，目标事件为实时对战类事件；服务器确定处于目标场景中的多个客户端，其中，多个客户端用于执行目标事件；服务器定时向多个客户端广播第一请求，其中，第一请求用于请求多个客户端同步执行第一事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第一事件的第一数据包，目标事件包括第一事件。本申请解决了相关技术中数据处理的开发成本高的技术问题。

Description

数据处理方法和装置、存储介质及电子装置
本申请要求于2017年6月8日提交中国专利局、优先权号为2017104307084、发明名称为“数据处理方法和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及数据处理领域，具体而言，涉及一种数据处理方法和装置、存储介质及电子装置。
背景技术
目前，在数据处理中，比如，在现代网络游戏市场中，越来越多的实时对战玩法已经出现。实时对战玩法因其带来的紧张、刺激的体验，受到了大量游戏玩家的欢迎。而实时对战玩法的具体分类非常多，常见的有多人在线战术竞技游戏类(Multiplayer Online Battle Arena Games，简称为MOBA)、即时战略游戏(Real-Time Strategy Game，简称为RTS)、射击类游戏类(Shooting Game，简称为STG)、飞行射击类、横版格斗类、赛车竞速类、各种球类比赛等。如此种类繁多的游戏，为了实现实时对战玩法，都需要开发一套利用网络来实时传送玩家操作、同步游戏状态的服务器系统，数据处理的开发成本高。
在实时对战的数据处理方法中，通常采用比较通用的广播服务器方案，以及具体某个游戏专用的方案。
在通用的广播服务器方案中，利用服务器来广播客户端的一些玩家操作，或者某些游戏状态的变更事件，以便使连接到这个服务器上的客户端，都能通过这些广播数据，同步游戏的状态。在通用的广播服务器方案中，比较著名的有客户端游戏引擎所自带的广播服务，比如，Unity3D就提供 了对游戏对象的特定数值的“同步”功能；再比如，Unreal引擎也有自己的游戏服务器端方案，具备广播功能。除了客户端游戏引擎外，还有一些更加通用的广播服务器，如Smart Fox Server这款利用JAVA开发的商业软件，通过设置一个“服务器端变量”的概念，让多个客户端都可以读、写这个变量，同时也可以收到这个变量变更通知，从而实现游戏状态同步的目的。另外，还采用Adobe Media Server这种用来广播视频流的服务器，以作为游戏状态广播的服务器。
但是，Unity/Unreal这类专业游戏引擎所带的广播服务器，一般都和其客户端引擎死死绑定，如果想用其他客户端技术，几乎是无法使用他们的服务器功能，因而通用性是一个问题。而Smart Fox Server/Adobe Media Server这一类的广播服务器功能，往往只有实时广播的功能，而缺乏实时对战游戏所需要的帧同步广播的功能。性能问题也是通用广播服务器的另一大缺点。上述游戏服务器基本上都不具备分布式能力，也即，只设计了让游戏玩家集中在一台服务器上玩的功能。如果用大量服务器组成一个服务器集群，则这些复杂的服务器端协调和通讯工作，就只能让开发者自己来解决。另外，这些服务器大部分都是商业软件，是不能修改的，而且其中一些是没有源代码的，因而要添加集群功能几乎是不可能的。
在具体某个游戏专用的方案中，采用专门的编写广播服务器。这些服务器的功能除了用于对多个客户端实现广播之外，通常还具备大量针对具体游戏业务逻辑的控制代码，比如，控制战场上怪物的生成、BOSS怪物的AI、物品奖励的掉落等等。
专用游戏服务器存在的问题，第一，通用性差，每款游戏都要重新开发一套，几乎每个专业的游戏都有一套独立的“战斗服务器”，由于每个游戏的玩法不一样，所以战斗服务器中运行的逻辑代码千差万别。这导致了每开发一款游戏，都要从头去编写这个“战斗服务器”，包括底层性能攸关的广播、通信代码，这就导致了很高的开发成本；第二，游戏逻辑和网络功能耦合，除错和实现负载均衡(运维)都比较困难，“战斗服务器” 由于是游戏中最重要的服务器之一，集中了大量复杂的游戏逻辑代码。因此战斗服务器也是故障最频繁，BUG出现概率最高的地方，由于战斗是一个持续在线的过程，所以大量的状态数据和网络包在战斗服务器中处理，这本身是一个多用户并发的复杂业务场景，不管是游戏逻辑，还是底层的网络状况出问题，都会导致这个复杂的实时系统出现故障，并且这种故障由于大部分状态都是在内存，而不是磁盘上，因而很难保留现场，所以战斗服务器的调试和除错，一直是一个难题。
针对上述的数据处理的开发成本高的问题，目前尚未提出有效的解决方案。
发明内容
本申请实施例提供了一种数据处理方法和装置、存储介质及电子装置，以至少解决相关技术中数据处理的开发成本高的技术问题。
根据本申请实施例的一个方面，提供了一种数据处理方法。该方法包括：服务器创建用于执行目标事件的目标场景，其中，目标事件为实时对战类事件；服务器确定处于目标场景中的多个客户端，其中，多个客户端用于执行目标事件；服务器定时向多个客户端广播第一请求，其中，第一请求用于请求多个客户端同步执行第一事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第一事件的第一数据包，目标事件包括第一事件。
根据本申请实施例的另一方面，还提供了一种数据处理装置，应用于服务器。该装置包括：创建单元，设置为创建用于执行目标事件的目标场景，其中，目标事件为实时对战类事件；确定单元，设置为确定处于目标场景中的多个客户端，其中，多个客户端用于执行目标事件；广播单元，设置为定时向多个客户端广播第一请求，其中，第一请求用于请求多个客户端同步执行第一事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第一事件的第一数据包，目标事件包括第一事件。
根据本发明的实施例的又一方面，还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述方法实施例中的步骤。
根据本发明实施例的又一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，上述处理器通过计算机程序执行上述方法实施例中的步骤。
在本申请实施例中，服务器创建用于执行目标事件的目标场景，其中，目标事件为实时对战类事件；服务器确定处于目标场景中的多个客户端，其中，多个客户端用于执行目标事件；服务器定时向多个客户端广播第一请求，其中，第一请求用于请求多个客户端同步执行第一事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第一事件的第一数据包，目标事件包括第一事件，由于定时向多个客户端广播第一请求，以使多个客户端同步执行第一事件，达到了通用广播服务器的帧同步广播的目的，从而实现了降低数据处理的开发成本的技术效果，进而解决了相关技术中数据处理的开发成本高的技术问题。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是根据本申请实施例的数据处理方法的硬件环境的示意图；
图2是根据本申请实施例的一种数据处理方法的流程图；
图3是根据本申请实施例的一种数据处理的结构示意图；
图4是根据本申请实施例的一种同时支持帧同步和即时广播功能的方法的流程示意图；
图5是根据本申请实施例的一种帧同步网络广播的方法的流程示意图；
图6是根据本申请实施例的一种数据冗余多发的方法的流程示意图；
图7是根据本申请实施例的一种断线重连的方法的流程示意图；
图8是根据本申请实施例的一致缓存发包的方法的流程示意图；
图9是根据本申请实施例的一种服务器端的架构图；
图10是根据本申请实施例的一种游戏房间操作流程的示意图；
图11是根据本申请实施例的一种消息分发流程的示意图；
图12是根据本申请实施例的客户端的登录流程的示意图；
图13是根据本申请实施例的一种开始流程的示意图；
图14是根据本申请实施例的一种帧同步流程的示意图；
图15是根据本申请实施例的一种广播流程的示意图；
图16是根据本申请实施例的一种P2P方式的同步游戏的示意图；
图17是根据本申请实施例的一种参数同步的接口方法的流程图；
图18是根据本申请实施例的一种数据处理装置的示意图；以及
图19是根据本申请实施例的一种终端的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描 述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
根据本申请实施例的一个方面，提供了一种数据处理方法的实施例。
可选地，在本实施例中，上述数据处理方法可以应用于如图1所示的由服务器102和终端104所构成的硬件环境中。图1是根据本申请实施例的数据处理方法的硬件环境的示意图。如图1所示，服务器102通过网络与终端104进行连接，上述网络包括但不限于：广域网、城域网或局域网，终端104并不限定于PC、手机、平板电脑等。本申请实施例的数据处理方法可以由服务器102来执行，也可以由终端104来执行，还可以是由服务器102和终端104共同执行。其中，终端104执行本申请实施例的数据处理方法也可以是由安装在其上的客户端来执行。
可选地，上述服务器可以为用于广播第一请求的服务器。
图2是根据本申请实施例的一种数据处理方法的流程图。如图2所示，该方法可以包括以下步骤：
步骤S202，服务器创建用于执行目标事件的目标场景。
在本申请实施例上述步骤S202提供的技术方案中，目标事件为实时对战类事件，为在数据处理过程中执行的实时对战类事件，可以为在执行某一局游戏时所产生的与游戏相关的实时同步的战斗游戏事件。目标场景为参与执行目标事件的客户端所处的场景，参与执行目标事件的客户端在目标场景中可以接收到服务器广播的数据，以保证同步处理数据。
可选地，目标场景为虚拟的房间。在这个房间内，所有的客户端都可以发送消息，服务器系统会向房间中的客户端广播这条消息，并且目标事件在执行时可以在运行时创建、销毁、进入、退出这些目标场景。
在目标事件的执行逻辑中，一旦开启一场需要实时同步的目标事件，就可以创建用于执行目标事件的目标场景。
该实施例通过创建用于执行目标事件的目标场景，从而实现了对目标场景的管理。
步骤S204，服务器确定处于目标场景中的多个客户端。
在本申请实施例上述步骤S204提供的技术方案中，多个客户端用于执行目标事件，针对任何目标事件的处理，参与的客户端都需要确定下来，也即，需要明确哪些客户端需要在目标场景中广播同一局的数据。在创建用于执行目标事件的目标场景之后，服务器确定处于目标场景中的多个客户端，多个客户端都可以在目标场景中发送消息。
该实施例的多个客户端并非与服务器绑定，该服务器的功能可以由多个客户端通用，其它客户端也可以在进入目标场景之后也可以与服务器进行通信，提高了事件处理功能的通用性。
在服务器确定处于目标场景中的多个客户端之后，就可以开始目标事件的同步数据广播了。
步骤S206，服务器定时向多个客户端广播第一请求。
在本申请实施例上述步骤S206提供的技术方案中，第一请求用于请求多个客户端同步执行第一事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第一事件的第一数据包，目标事件包括第一事件。
普通的即时广播，可以用于实现游戏中的频道聊天、准备状态通知等同步性要求不高的功能，该实施例不只是在收到第一请求时，就立刻广播，而且还支持以帧同步的方式进行广播。该实施例的第一请求为需要服务器广播的请求，可以由客户端中的至少一个客户端发送，并且携带有用于执行目标事件中的第一事件的第一数据包，该第一数据包可以包括用于控制游戏角色执行的动作的帧数据。可选地，帧同步的广播功能可以通过用户数据报协议(User Datagram Protocol，简称为UDP)进行实现。
在服务器确定处于目标场景中的多个客户端之后，服务器定时向多个客户端广播第一请求以实现广播数据的目的，可以由定时器在固定的时间广播数据。帧同步广播是一种服务器自动搜集客户端输入组包，然后定时发送广播的游戏开发功能，由服务器定时广播数据包，以驱动客户端渲染帧的实时网络画面同步，几乎所有的实时动作网游游戏，都可以使用这个功能。
可选地，帧同步只有满足以下条件之一才会开始：所有客户端都准备好，服务器(LockStep Server)超时，服务器(LockStep Server)的其它机制满足条件。帧数据由服务器(LockStep Server)按照自己的定时器在固定的时间产生，即使没有任何用户输入，也会生成空帧。客户端会自动检查每个帧同步包的序号，如果出现丢失，则启动TCP的下载通道，向中继服务器(RelayServer)去下载缺失的帧，而这个时候PopFrame()接口将不会返回帧数据，直到所有的缺失帧补齐，才按顺序返回完整的帧数据。
上述两种广播功能，可以通过两个不同的接口提供。其中，帧同步的广播方式是不管服务器有没有收到客户端发送的请求，都会定时对同一目标场景中的其它客户端进行广播，其中，广播的频率可以配置，比如，广播的频率为0.1秒到0.05秒；如果任何数量的客户端都向服务器发送请求，服务器会保存这些需要广播的请求，在下一次定时广播的数据包内集中起来，再向所有客户端发送。
该实施例的广播通道不依赖于目标事件是否开始执行，只要客户端成功登录之后就可以进行收发数据。广播数据一旦到达客户端的软件开发工具包(Software Development Kit，简称为SDK)，立刻回调用户定义的收包函数进行处理。
该实施例的以上功能，用户在使用的时候，需要通过客户端接口和服务器端接口来调用，该实施例可以抽象实时对战类事件的共性，统一地完成上述在事件处理中的功能，提供了多个客户端同步处理所需的广播能力，是一种接入即可用的数据处理方法，只需要开发具体的客户端代码，即可 以快速地实现网络实时对战事件的处理功能，提高了数据处理效率，降低了数据处理的开发成本。
通过上述步骤S202至步骤S206，由于服务器定时向多个客户端广播第一请求，以使多个客户端同步执行第一事件，达到了通用广播服务器的帧同步广播的目的，从而实现了降低数据处理的开发成本的技术效果，进而解决了相关技术中数据处理的开发成本高的技术问题。
作为一种可选的实施方式，步骤S206，服务器定时向多个客户端广播第一请求包括：服务器接收第一数量的客户端发送的第一请求；在接收到第一请求之后，服务器在第一时间向多个客户端广播第一请求。
多个客户端包括第一数量的客户端。在服务器确定处于目标场景中的多个客户端之后，服务器可以接收多个客户端中的任何数量的客户端发送过来的第一请求，服务器都会保存这些需要广播的请求。
在接收到第一请求之后，服务器在第一时间向多个客户端广播第一请求，第一时间与上一次向多个客户端广播第二请求的时间相隔第一预设时间，第二请求用于请求多个客户端同步执行第二事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第二事件的第二数据包，目标事件包括第二事件。
服务器会定时对同一目标场景中的客户端进行广播。在接收到第一数量的客户端发送的第一请求之后，服务器会保存这些第一请求，在第一时间向多个客户端广播第一请求。可选地，服务器将第一数量的客户端发送的第一请求在定时广播的数据包内集中起来，在第一时间向多个客户端广播第一请求。该第一时间为定时到达的时间，与上一次服务器向多个客户端广播第二请求的时间相隔第一预设时间，该第一预设时间可以设置，比如，第一预设时间为0.1秒到0.05秒，第二请求与第一请求类似，用于请求多个客户端同步执行第二事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第二事件的第二数据包，上述目标事件包括第二事件。
作为一种可选的实施方式，步骤S206，服务器定时向多个客户端广播第一请求包括：当第一时间到达时，且未接收到任何多个客户端发送的请求的情况下，向多个客户端广播携带空帧的第一请求。
在服务器定时向多个客户端广播第一请求时，服务器无论有没有收到客户端发送的请求，都会相隔第一预设时间对同一目标场景内的客户端广播接收到的请求。当第一时间到达时，且未接收到任何多个客户端发送的请求的情况下，服务器仍然向多个客户端广播携带空帧的第一请求，也即，即使客户端没有任何输入，也会生成空帧，从而实现通用服务器的帧同步的广播功能。
作为一种可选的实施方式，步骤S206，服务器定时向多个客户端广播第一请求包括：服务器分别获取前N次向多个客户端广播的请求中所携带的N个数据包；服务器定时向多个客户端广播携带有N个数据包和第一数据包的第一请求。
服务器分别获取前N次向多个客户端广播的请求中所携带的N个数据包，N次与N个数据包一一对应，N为大于等于1的自然数。
在对战类事件的数据处理的过程中，比如，在实时同步动作游戏开发的过程中，网络会出现延迟波动、偶发丢包、短暂断线等问题，因而需要对弱网络环境进行优化。
在帧同步广播的时候，每个数据包，实际上都会重发多次，也即，每次广播的数据包都会带上之前几次应该发的数据包中的内容。在确定处于目标场景中的多个客户端之后，服务器分别获取前N次向多个客户端广播的请求中所携带的N个数据包，N次为数据包的重发次数，与N个数据包一一对应，为大于等于1的自然数，是可以进行设置的。
在分别获取前N次向多个客户端广播的请求中所携带的N个数据包之后，服务器定时向多个客户端广播携带有N个数据包和第一数据包的第一请求，从而实现了一种使用冗余多发的策略来降低丢包带来的影响。
该实施例通过上述方法实现了定时向多个客户端广播第一请求的目的，针对网络出现的延迟波动、偶发丢包等问题做了特别优化，而不需要开发者过多关注，从而实现了一种使用冗余多发的策略来降低丢包带来的影响。
作为一种可选的实施方式，在步骤S206，服务器定时向多个客户端广播第一请求之后，记录第一数据包；服务器定时向多个客户端广播第三请求；记录第三数据包。
在服务器端记录下目标事件在目标场景中执行过程中所广播过的所有数据包。在定时向多个客户端广播第一请求之后，记录第一数据包，从而实现对第一数据包保存，以在客户端出现断线重连的情况下，可以再次向客户端发送未接收到的第一数据包。
服务器定时向多个客户端广播第三请求，该第三请求用于请求多个客户端同步执行第三事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第三事件的第三数据包，目标事件包括第三事件。
在记录第一数据包之后，服务器接收到多个客户端中的至少一个客户端发送的第三请求，当定时时间到达时，向多个客户端广播第三请求，该第三请求携带有由多个客户端中的至少一个客户端发送的用于执行第三事件的第三数据包，目标事件包括第三事件，
在服务器定时向多个客户端广播第三请求之后，记录第三数据包，从而实现对第三数据包保存，以在客户端出现断线重连的情况下，可以再次向客户端发送未接收到的第三数据包。
该实施例通过上述方法达到了在服务器端记录下目标场景下广播过的所有数据包的目的，以在客户端断线重连期间未接收到的数据包。
作为一种可选的实施方式，在步骤S206，服务器定时向多个客户端广播第一请求之后，该方法还包括：在多个客户端中的第一客户端失去连接，且在记录第三数据包之后重新建立连接的情况下，服务器向第一客户 端发送第一数据包和第三数据包，多个客户端中的第一客户端失去连接包括：多个客户端中的第一客户端所处的网络断线；或者多个客户端中的第一客户端退出事件执行进程。
在弱网络情况下，网络出现延迟波动、偶尔丢包、短暂断线的情形。由于在断线之后，会导致数据包丢失，也即，在定时向多个客户端广播第一请求之后，在多个客户端中的第一客户端失去连接，且在记录第三数据包之后重新建立连接的情况下，服务器第一客户端在失去连接的过程中未接收到第一数据包和第三数据包。由于在服务器端已经记录下第一数据包和第二数据包，向第一客户端发送第一数据包和第三数据包，实现客户端快速获取未接收到的数据包，从而避免客户端丢包的情况出现，提高数据处理效率。
可选地，数据包通过序列号进行标识，每个数据包的序列号具有预设顺序。客户端在断线重新连接之后，会自动从上次断线之后最后广播的数据包的序列号开始，重新下载未接收到的，且服务器记录过的数据包。
可选地，多个客户端中的第一客户端失去连接包括两种情况，第一种情况因为网络断线，在这种情况下，第一客户端可以调用接口重新登录；第二种情况为第一客户端退出事件执行的进程，比如，游戏玩家退出游戏进程，此时目标场景中的地址信息、键值信息、当前帧的帧号等信息丢失，客户端需要重新登录，并从第一帧(PopFrame)开始同步数据。需要说明的是，客户端在收到第一帧时，即可以认为目标事件开始执行。
作为一种可选的实施方式，在步骤S206，服务器定时向多个客户端广播第一请求之后，在多个客户端中的第一客户端失去连接，且在记录第三数据包之后重新建立连接的情况下，服务器接收客户端发送的自定义的第四请求；服务器响应第四请求，并向第一客户端发送第一数据包或第三数据包。
在多个客户端中的第一客户端失去连接，且在记录第三数据包之后重新建立连接的情况下，服务器接收客户端发送的第四请求。第四请求用于 请求获取第一数据包或第三数据包，第一客户端在失去连接的过程中未接收到第一数据包和第三数据包。
在服务器定时向多个客户端广播第一请求之后，在多个客户端中的第一客户端失去连接，且在记录第三数据包之后重新建立连接的情况下，客户端可以自定义选择未接收到的，且服务器已经记录过的数据包进行接收。接收客户端发送的自定义的第四请求，该第四请求用于请求获取客户端自定义选择的第一数据包或第三数据包。
可选地，客户端也可以自定义从某一个数据包对应的序列号开始下载，这适用于游戏自己有实现状态快照的情况，也即，适用于定时在客户端记录下游戏中的状态的情况，这样可以通过恢复最近的状态快照，从此状态快照处开始下载丢失的数据，其中，状态快照处根据广播的数据包的序列号确定。这个功能也可以用来做游戏的录像重播，由于只记录游戏的操作数据，因而这种游戏录像比视屏录像保存的文件小很多。
服务器响应第四请求，并向第一客户端发送第一数据包或第三数据包，在服务器接收到客户端发送的第四请求之后，响应第四请求，向第一客户端发送第一数据包或第三数据包。
需要说明的是，上述第一数据包和第三数据包并不限定服务器只广播第一数据包和第二数据包，只要是服务器定时向客户端广播的请求中携带的数据包都在本申请的保护范围之内，此处不再一一举例说明。
该实施例通过上述方法实现了客户端快速获取未接收到的数据包，从而避免客户端丢包的情况出现，提高数据处理效率。
作为一种可选的实施方式，服务器记录第一数据包包括：在第一数据包不为空帧的情况下，服务器记录第一数据包；服务器记录第三数据包包括：在第三数据包不为空帧的情况下，服务器记录第三数据包。
在服务器定时向多个客户端广播第一请求之后，记录第一数据包，在第一数据包不为空帧的情况下，记录第一数据包，也即，当第一数据包为 空帧的时候，则不会在服务器中保留。在定时向多个客户端广播第三请求之后，在第三数据包不为空帧的情况下，记录第三数据包，也即，当第三数据包为空帧的情况下，则不会在服务器中保留。因而，断线重连的客户端不会再次获取空帧的数据包。
作为一种可选的实施方式，第一数据包通过第一序列号进行标识，第三数据包通过第二序列号进行标识，其中，第一序列号和第二序列号连续。
服务器每次广播的数据包通过序列号进行标识，也即，每个数据包具有唯一的序列号，每个数据包的序列号可以随着发送时间的递增而连续递增，这样当存在丢包的情况下，客户端可以根据多个连续序列号中缺失的序列化确定丢失的数据包。第一数据包通过第一序列号进行标识，第三数据包为在第一数据包发送之后发送的数据包，通过第二序列号进行标识，第一序列号和第二序列号连续。
作为一种可选的实施方式，步骤S206，服务器定时向多个客户端广播第一请求包括：服务器定时向每个客户端的缓冲区发送第一数据包，其中，第一数据包定时由每个客户端进行处理。
在弱网络下，延迟波动会影响画面的忽快忽慢，从而难以准确把握输入和响应之间的提前量。在客户端处建立一定大小的缓冲区，服务器定时向每个客户端的缓存区发送第一数据包，客户端在收到第一数据包之后不立刻处理，而是先放入缓冲区，然后定时将缓冲区中的第一数据包由客户端代码进行处理，这样客户端得到的数据包就会在一定时间段内的处理速度都是比较稳定的。可选地，客户端在收到网络广播包之后，不立刻通知游戏逻辑代码，而是先放入缓冲区，然后定时把缓冲区的数据包通知给游戏客户端代码。这样客户端代码就会在一定时间段内稳定地处理得到的数据包。虽然这会增加整体网络数据包的延迟，但是能让所有的网络包的到达速度保持一致，从而为用户形成一个稳定的操作手感，提升用户体验。
作为一种可选的实施方式，在步骤S206，服务器定时向多个客户端广播第一请求时，该方法还包括：在验证出第一数据包不合法的情况下， 服务器禁止发送第一数据包的客户端执行目标事件，和/或服务器记录用于指示第一数据包不合法的信息。
验证第一数据包是否合法，在对战类事件处理的过程中，可能出现作弊的情况。需要服务器对数据包进行合法性验证。在定时向多个客户端广播第一请求时，验证第一数据包是否合法。
可选地，网络游戏一般都要面对外挂和破解的威胁，在游戏的实时战斗过程中，往往也需要对广播的数据包进行合法性验证。
在验证出第一数据包不合法的情况下，服务器禁止发送第一数据包的客户端执行目标事件，和/或服务器记录用于指示第一数据包不合法的信息。在验证第一数据包是否合法之后，在验证出第一数据包不合法的情况下，服务器禁止发送第一数据包的客户端执行目标事件，比如，在游戏处理事件中，当发现某个客户端作弊时，服务器可以禁止作弊客户端在目标场景中执行游戏事件，也即，将作弊客户端“剔除”本局游戏。
可以获取作弊客户端的完整作弊记录，以用于后期对客户端进一步的处理，比如，根据作弊客户端的完整作弊记录对作弊客户端进一步惩罚和预防。
该实施例服务器端接口，拥有客户端接口的全部功能，再额外增加了对目标场景的管理能力，降低了数据处理的开发成本。
作为一种可选的实施方式，服务器验证第一数据包是否合法包括：服务器通过第一服务器验证第一数据包是否合法。
服务器向第一服务器广播第一数据包，将所有向客户端广播的数据，都同样的向第一服务器广播，该第一服务器可以为开发者所设置的游戏服务器(GameServer)，这样游戏服务器就能实时地掌握所有客户端收到的数据包，从而进行任何需要获取的验证鉴权，其中，游戏服务器用于在一般网络游戏中，运算主要的游戏逻辑的服务器进程。
在服务器向第一服务器广播第一数据包之后，通过第一服务器验证第 一数据包是否合法。当游戏服务器发现有某个客户端作弊，开发者不但可以立刻把有问题的客户端“踢出”本局游戏，而且可以获得完整的作弊记录，用作日后的进一步惩罚和预防。
该实施例通过上述方法实现了验证第一数据包是否合法的目的。
作为一种可选的实施方式，在通过第一服务器验证第一数据包是否合法之后，该方法还包括：在通过第一服务器验证第一数据包不合法的情况下，通过第一服务器设置预设操作信息；通过第一服务器向多个客户端中除发送第一数据包的客户端之外的客户端广播预设操作信息。
在通过第一服务器验证第一数据包不合法的情况下，通过第一服务器设置预设操作信息，预设操作信息用于指示多个客户端中除发送第一数据包的客户端之外的客户端执行预设操作。
在通过第一服务器验证第一数据包不合法的情况下，确定与第一数据包的客户端为作弊客户端，踢出第一数据包的客户端。预设操作信息用于指示多个客户端中除发送第一数据包的客户端之外的客户端执行预设操作，比如，在游戏中掉落战利品。
在通过第一服务器设置预设操作信息之后，通过第一服务器向多个客户端中除发送第一数据包的客户端之外的客户端广播预设操作信息，比如，通过服务器的广播接口将掉落的战利品的数据信息向存在于目标场景中的客户端发送。
该实施例通过上述方法实现了目标场景下的信息的广播。
作为一种可选的实施方式，步骤S202，服务器创建用于执行目标事件的目标场景包括：服务器通过调用预设接口创建目标场景；和/或服务器通过预设接口向多个客户端发送目标场景的信息，其中，目标场景的信息包括以下至少之一：目标场景的地址信息；目标场景的键值信息；目标场景的统一资源定位符。
服务器在建用于执行目标事件的目标场景时，调用预设接口，该预设 接口可以为LockStep Service的接口，通过该接口创建目标场景。可选地，在通过调用预设接口创建目标场景之后，通过预设接口向多个客户端发送目标场景的信息，该目标场景的信息包括目标场景的地址信息、目标场景的键值信息、目标场景的统一资源定位符等。
可选地，在游戏玩家连上GameSvr大厅后，发起5V5对战，GameSvr通过调用LockStep Service的接口创建PVP房间，LockStep Service会返回各个成员的RoomID，RoomKey以及房间Url，通过GameSvr将此信息返回给客户端。
作为一种可选的实施方式，步骤S206，服务器定时向多个客户端广播第一请求包括：服务器获取每个客户端的操作信息；将每个客户端的操作信息组合为数据帧；服务器定时向多个客户端广播携带有数据帧的第一请求。
在确定目标场景下的每个客户端之后，服务器获取每个客户端的操作信息，也即，收集每个客户端的动作信息。
在获取每个客户端的操作信息之后，服务器将每个客户端的操作信息组合为数据帧，也即，组成一个完整的帧内容。
在将每个客户端的操作信息组合为数据帧之后，服务器定时向多个客户端广播携带有数据帧的第一请求，以将数据帧向目标场景中的其他游戏玩家对应的客户端广播。
该实施例通过上述方法实现了定时向多个客户端广播第一请求的目的，由于定时向多个客户端广播第一请求，以使多个客户端同步执行第一事件，达到了通用广播服务器的帧同步广播的目的。
作为一种可选的实施方式，步骤S202，服务器创建用于执行目标事件的目标场景包括：服务器获取多个第二服务器的场景信息；接收场景创建请求，并根据多个第二服务器的场景信息确定用于创建目标场景的目标服务器；服务器向目标服务器发送创建指令；在目标服务器接收到创建指 令之后，通过目标服务器创建目标场景。
服务器获取多个第二服务器的场景信息，每个第二服务器的场景信息包括用于指示每个第二服务器允许创建的场景和已经创建的场景的信息。
在创建用于执行目标事件的目标场景时，服务器获取多个第二服务器的场景信息，该第二服务器可以为房间服务器(RoomSvr)，每个第二服务器会定期向所有的场景管理服务器(RoomMng)上报每个第二服务器的场景信息，该场景信息用于指示每个第二服务器允许创建的场景和已经创建的场景的信息。比如，RoomSvr会定期向所有RoomMng上报自身的信息，包括总共支持多少房间，当前已创建了多少房间等，其中，RoomSvr上存有房间的具体信息，以及该房间所有产生的帧数据，进程崩溃(Crash)之后，对应房间的信息将丢失，让业务侧重新创建房间即可，可平行扩展，根据业务需要可动态扩容；RoomMng主要功能是收集各个RommSvr的状态，管理房间的创建，具体房间信息是存在Tcaplus中，而不是在RoomMng的内存中，进程崩溃后可以立即重启并向RoomSvr拉取信息，迅速恢复服务，可平行扩展，内存和CPU消耗不会太大，在一个集群里部署两个节点即可。
服务器接收场景创建请求，并根据多个第二服务器的场景信息确定用于创建目标场景的目标服务器，场景创建请求用于请求创建目标场景。
在服务器获取多个第二服务器的场景信息之后，接收用于请求创建目标场景的场景创建请求，该场景创建请求会随机落在一个RoomMng上，RoomMng收到请求后，会综合当前所有的第二服务器的负载情况，选择一个目标服务器以发送创建房间的命令。
服务器向目标服务器发送创建指令，该创建指令用于指示目标服务器创建目标场景。
在根据多个第二服务器的场景信息确定用于创建目标场景的目标服务器之后，服务器向目标服务器发送创建指令，以指示目标服务器创建目 标场景。
在目标服务器接收到创建指令之后，服务器向目标服务器发送创建指令，通过目标服务器创建目标场景，并给目标场景中的每个客户端分配一个随机键，该随机键可以用于后续客户端到服务器之间的信息传输时为信息加密或者解密。
该实施例通过上述方法实现了创建用于执行目标事件的目标场景的目的，进而确定处于目标场景中的多个客户端；定时向多个客户端广播第一请求，以使多个客户端同步执行第一事件，达到了通用广播服务器的帧同步广播的目的，从而实现了降低数据处理的开发成本的技术效果。
作为一种可选的实施方式，在步骤S202，服务器创建用于执行目标事件的目标场景之后，该方法还包括以下之一：在多个客户端执行目标事件之后，服务器关闭目标场景；在多个客户端退出目标场景之后，服务器关闭目标场景；在第二预设时间内未与多个客户端通信时，服务器关闭目标场景；在创建目标场景的时间超过第三预设时间时，服务器关闭目标场景。
在创建用于执行目标事件的目标场景之后，服务器可以对创建的目标场景进行关闭，包括：在多个客户端执行目标事件之后，服务器关闭目标场景，可选地，游戏服务器(GameSvr)主动销毁房间，包括对战正常结束，或者游戏发现客户端作弊而异常关闭的，消息路径可以为GameSvr->RoomMng->Tcaplus；在多个客户端退出目标场景之后，关闭目标场景，可选地，RoomSvr收到了所有客户端退出房间的消息，而关闭房间，这个是对应正常的PVP战斗结束流程，消息路径可以为RoomSvr->RoomMng->Tcaplus；在第二预设时间内未与多个客户端通信时，关闭目标场景，可选地，RoomSvr上因为房间若干时间没消息通信而关闭房间，这种主要为防止PVP已经正常结束，但GameSvr和客户端没有主动调用关闭房间的情况，消息路径可以为RoomSvr->RoomMng->Tcaplus；在创建目标场景的时间超过第三预设时间时，关闭目标场景，可选地，自 动扫描工具扫描Tcaplus表中超过2天前建立的房间，将其关闭，这种是为防止RoomSvr重启导致房间信息丢失的情况，消息路径为CleanTool->Tcaplus，其中，Tcaplus为一款IEG研发部自主研发的存储系统，CleanTool为清除数据的工具。
作为一种可选的实施方式，在步骤S204，服务器确定处于目标场景中的多个客户端之后，该方法还包括：服务器对多个客户端的登录信息进行校验；在对至少一个客户端的登录信息校验失败的情况下，服务器发送校验失败信息；在对多个客户端的登录信息校验成功的情况下，服务器将多个客户端发送的数据设置为空帧。
在确定处于目标场景中的多个客户端之后，服务器对多个客户端的登录信息进行校验，对每个客户端的键值(MemberKey)进行校验。
在对多个客户端的登录信息进行校验之后，在对至少一个客户端的登录信息校验失败的情况下，服务器发送校验失败信息，也即，如果客户端的登录信息校验失败，则返回错误信息。
在对多个客户端的登录信息进行校验之后，在对多个客户端的登录信息校验成功的情况下，服务器将多个客户端发送的数据设置为空帧，可以将多个客户端发送的数据的当前帧号(FrameId)标记为0，并且FrameId为0的数据不会保留，也即，在客户端断线重连之后，不会收到FrameId为0的数据。
可选地，对局登录会对MemberKey进行校验，如果失败返回错误信息。在登录阶段，将服务器对局状态标记为Login，这个时候服务器会对客户端的输入进行转发，但FrameId标记为0，并且FrameId为0的数据不会在LockStepSvr保留，也即，断线重连上来的客户端不会收到FrameId为0的数据。
该实施例通过上述方法实现了目标场景下的客户端的登录。
作为一种可选的实施方式，步骤S206，服务器定时向多个客户端广 播第一请求包括：服务器接收多个客户端发送的第五请求；响应第五请求，并允许定时向多个客户端广播第一请求。
服务器接收多个客户端发送的第五请求，第五请求用于请求开始执行目标事件。
在定时向多个客户端广播第一请求时，服务器接收多个客户端发送的第五请求，该第五请求用于请求开始执行目标事件。可选地，对局开始的时机为服务器接收到所有客户端的发送的第五请求才开始正式进行对局转发，该第五请求可以为对战开始请求(BattleStart)。
在接收多个客户端发送的第五请求之后，服务器响应第五请求，此时将当前帧号FrameId标记为1，表示帧同步正式开始，并允许定时向多个客户端广播第一请求。
该实施例通过上述方法实现了开始定时向多个客户端广播第一请求的目的。
作为一种可选的实施方式，服务器允许定时向多个客户端广播第一请求包括：在未全部接收到多个客户端发送的第五请求的情况下，服务器在第三预设时间允许定时向多个客户端广播第一请求。
服务器允许定时向多个客户端广播第一请求时，在未全部接收到多个客户端发送的第五请求的情况下，也即，只收到了部分客户端发送的第五请求，服务器会触发一个超时机制，在第三预设时间允许定时向多个客户端广播第一请求，比如，在收到第一客户端发送的第五请求之后10秒，也会启动帧同步流程，上述第三预设时间可以由服务器进行设定。
作为一种可选的实施方式，在步骤S206，服务器定时向多个客户端广播第一请求之后，该方法还包括：服务器接收多个客户端发送的第六请求，其中，第六请求用于请求结束执行目标事件；服务器响应第六请求，并关闭目标场景以使多个客户端结束执行目标事件。
服务器接收多个客户端发送的第六请求，第六请求用于请求结束执行 目标事件。
在定时向多个客户端广播第一请求之后，可以结束多个客户端对目标事件的执行。服务器接收多个客户端发送的第六请求，该第六请求用于请求结束预设时间。可选地，客户端调用结束接口(Stop接口)，此时丢弃客户端的输入。
在接收到多个客户端发送的第六请求之后，服务器响应第六请求，并关闭目标场景以使多个客户端结束执行目标事件，目标场景进入销毁状态。
该实施例通过上述方法实现了多个客户端结束执行目标事件的目的。
作为一种可选的实施方式，步骤S206，服务器定时向多个客户端广播第一请求包括：服务器获取帧同步参数；按照帧同步参数获取多个客户端发送的数据包；服务器对多个客户端发送的数据包进行打包处理，得到第一数据包。
服务器获取帧同步参数，帧同步参数用于指示每秒传输的帧数。
帧同步参数在目标场景创建的时候就传入，用于指示每秒传输的帧数，比如，帧同步参数为15帧/s，用于指示每秒传输15帧。
在获取帧同步参数之后，服务器按照帧同步参数获取多个客户端发送的数据包，可以自发出去的第1帧开始，对当前FrameId进行自增策略，获取多个客户端发送的数据包。
服务器对多个客户端发送的数据包进行打包处理，得到第一数据包，第一数据包至少包括：每个客户端的标识信息、当前帧号、每个客户端发送的数据包。
在按照帧同步参数获取多个客户端发送的数据包之后，服务器对多个客户端发送的数据包进行打包处理，得到第一数据包，可以在n帧和n+1帧之间，对所有客户端的输入数据包进行打包处理，得到第一数据包。
在对多个客户端发送的数据包进行打包处理，得到第一数据包之后， 服务器向多个客户端广播第一数据包，也即，将第一数据包广播至目标场景中的所有客户端。
可选地，该实施例的服务器向客户端下发的第一数据包包括：每个客户端的标识信息、当前帧号、每个客户端发送的数据包，其中，每个客户端的标识信息用于唯一标识每个客户端，每个客户端发送的数据包为客户端的输入信息。
该实施例通过上述方法实现了定时向多个客户端广播第一请求的目的，达到了帧同步的技术效果。
作为一种可选的实施方式，服务器向多个客户端广播第一数据包包括：在第一数据包超过预设传输量的情况下，服务器在当前帧中向多个客户端广播在预设传输量之内的第一数据包，其中，超出预设传输量的第一数据包在当前帧的下一帧中进行打包处理。
该实施例的预设传输量可以为最大传输单元(Maximum Transmission Unit，简称为MTU)，为通信协议的某一层上面所能通过的最大数据报大小，该预设传输量可以以字节为单位。在向多个客户端广播第一数据包时，在第一数据包超过预设传输量的情况下，在当前帧中向多个客户端广播在预设传输量之内的第一数据包。可选地，在在n帧和n+1帧之间，如果m个客户端输入(input)了k个消息，则服务器打包得到m*k个消息，如果超过了MTU，则将超出的消息放到下一帧去进行打包。在n帧和n+1帧之间，如果m个客户端没有输入，则自增当前FrameId，同时广播所有客户端，但不打包任何消息。
作为一种可选的实施方式，步骤S206，服务器定时向多个客户端广播第一请求包括：在多个客户端中的至少一个客户端接收到的第一数据包的第一序列号与至少一个客户端之前接收的数据包的第三序列号不连续的情况下，服务器接收至少一个客户端发送的第七请求；响应第七请求，并向至少一个客户端发送第四序列号标识的数据包。
在多个客户端中的至少一个客户端接收到的第一数据包的第一序列号与至少一个客户端之前接收的数据包的第三序列号不连续的情况下，服务器接收至少一个客户端发送的第七请求，其中，第七请求用于请求获取第四序列号标识的数据包，第一序列号用于标识第一数据包，第三序列号用于标识至少一个客户端之前接收的数据包，第四序列号位于第一序列号与第三序列号之间，且与第一序列号和第三序列号连续。
在该实施例中，服务器和客户端的接口进行配合，以保证数据包的序列号是连续的。如果数据包的序列号不连续，则会主动发送请求以获取丢失的帧(LostFrame)。
在接收至少一个客户端发送的第七请求之后，服务器响应第七请求，并向至少一个客户端发送第四序列号标识的数据包，从而实现丢包补偿策略。
可选地，帧同步默认冗余2帧信息，最大冗余3帧信息，可以根据用户网络环境自适应切换。
该实施例通过上述方法实现了定时向多个客户端广播第一请求的目的。
作为一种可选的实施方式，通过服务器接口和客户端接口调用数据处理方法。
可选地，该实施例的客户端通过Tconnd访问用于创建目标场景的服务器RoomSvr，客户端到Tconnd之间采用用户数据报协议UDP透传模式，Tconnd上不进行数据加解密，加解密的工作由RommSvr完成。其中，Tconnd为一款IEG研发部自主研发的网络接入组件进程，可以把并发的网络连接(TCP/UDP)数据，转换成对内网进程的消息队列请求，用于解耦网络连接处理和业务逻辑，为接入层，无状态，进程重启不影响服务功能。
RoomMng主要功能是收集各个RommSvr的状态，管理房间的创建， 具体房间信息是存在Tcaplus中，而不是在RoomMng的内存中，进程Crash后可以立即重启并向RoomSvr拉取信息，迅速恢复服务。
RoomSvr上存有房间的具体信息，以及该房间所有产生的帧数据，进程Crash后，对应房间的信息将丢失，由于PVP一场对局持续时间不会太久，所以影响不大，让业务侧重新创建房间即可。Tconnd为接入层，无状态，进程重启不影响服务功能。
该实施例可以通用于需要帧同步机制的实时同步游戏，也可以用于最简单的网络聊天室应用。在游戏应用中，除了支持帧同步，也支持部分状态同步的同步实现方法，使用起来非常灵活。该实施例可以使没有能力，或者不想自己编写帧同步机制的游戏开发团队，也能很简单的使用帧同步这种技术，来开发自己的游戏。并且使用这种技术，并不需要源代码上的授权，仅仅接入本系统的SDK即可。
下面结合一种可选的实施例对本申请的技术方案进行说明，具体以目标事件为游戏事件，目标场景为房间进行举例说明。
图3是根据本申请实施例的一种数据处理的结构示意图。如图3所示，数据处理包括中继管理进程(RelayMgr)、中继服务器(RelaySvr)、接入组件进程(Tconnd)、客户端(Client)、游戏服务器(GameSvr)、服务接口(LockStep Service Api)，中继管理进程与服务接口之间进行交互，实现创建房间和关闭房间，中继服务器向服务器接口传输数据帧，接入组件与客户端之间传出数据帧，客户端与游戏服务器之间采用游戏逻辑。
一般游戏开发者，需要在客户端和服务器端两侧都接入该实施例描述的通用实时同步服务器系统，简称为服务器系统。在该实施例中，服务器系统主要提供游戏同步所需的广播能力。下面对其进行详细介绍：
下面对房间管理进行介绍。
针对任何一局游戏，参与的玩家都需要确定下来。也即，需要明确哪几个客户端需要广播同一局的数据。将需要一起工作的客户端称为进入了 一个虚拟的房间。在这个房间内，所有的客户端都可以发送消息，服务器系统会将这条消息向所有其他在这个房间里的客户端进行广播。由于游戏需要在运行时创建、销毁、进入、退出这些虚拟房间，所以服务器系统需要提供这些能力。在游戏逻辑中，一旦开启一场需要实时同步的战斗，就可以调用服务器系统的上述功能去创建一个房间，然后让客户端进入这个房间，以开始游戏的同步数据广播。
下面对广播数据的功能进行介绍。
广播数据是本系统最主要的功能，但该实施例不只是收到一个请求包就立刻广播，而且还支持以帧同步的方式进行广播。这两种广播功能，通过两个不同的接口提供。其中，帧同步的广播方式为，服务器不管有没有接收到客户端的请求，都会定时(频率可配置，一般为0.1秒到0.05秒)对同一房间内的其它客户端进行广播；如果任何数量客户端发送请求来，服务器都会保存这些需要广播的请求，再下一次定时广播的包内集中起来，最后发到所有客户端上。可选地，普通的即时广播，可以用来做游戏中的频道聊天、准备状态通知等同步性要求不高的功能；帧同步则可以同时作为游戏中动作同步的实现。
图4是根据本申请实施例的一种同时支持帧同步和即时广播功能的方法的流程示意图。如图4所示，客户端1(1P Client)向中继服务器(Relay Server)广播输入数据(Input)，中继服务器将客户端1的输入数据广播至客户端2(2P Client)。
图5是根据本申请实施例的一种帧同步网络广播的方法的流程示意图。如图5所示，客户端1P向服务器端发送数据Opr1和Opr4，客户端2P向服务器端发送数据Opr2和Opr3，服务器端将客户端1P发送的数据Opr1和Opr4和客户端2P发送的数据Opr1和Opr4以及空帧(Empty)向客户端1P和客户端2P广播，实现了服务器不管有没有收到客户端的请求，都定时对同一房间内的其它客户端进行广播。
下面对弱网络优化的方法进行介绍。
在实时同步动作游戏开发中，网络会出现延迟波动、偶发丢包、短暂断线这一类问题。该实施例针对上述问题做了优化，而不需要开发者过多关注。
图6是根据本申请实施例的一种数据冗余多发的方法的流程示意图。如图6所示，该实施例包括客户端1(Client1)、客户端2(Client2)、客户端3(ClientN)，客户端1向云服务器(Lock Step Cloud)输入数据Input1、Input2、Input3，客户端2输入数据Input1、Input2，客户端3输入数据Input1，拂去其返回第一帧数据Frame1、Frame2、Frame3、其中，Frame1包括数据Client1.Input1、Client2.Input1、Client3.empty；Frame2包括数据Client1.Input2、Client2.empty、Client3.empty；Frame3包括数据Client1.Input3、Client2.Input2、Client3.Input1。使用冗余多发的策略来降低丢包带来的影响，在帧同步广播的时候，每个数据包，实际上都会重发2至3遍，也即，每个数据包都会带上之前两次应该发的数据包的内容。这个重发的次数是可以设置的，从而解决丢包数据传输过程中的丢包问题。
对于由于弱网络环境而引起的断线重连的问题，由于在断线之后，大量的数据包丢失，此系统会在服务器端记录下整局游戏所广播过的所有包，客户端在断线重新连接之后，会自动从上次断线的最后一个广播包的序列号开始，重新下载所有记录过的数据包，然后重新加速运算整局游戏。客户端也可以自定义从某一个序列号开始下载，这适用于游戏自己有实现状态快照的情况，也即，定时在客户端记录下游戏中的状态情况，这样可以通过恢复最近的状态快照，然后从此状态快照处(根据广播包序列号确定)开始下载丢失的广播数据。这个功能也可以用来做游戏的录像重播，由于只记录的游戏的操作数据，所以这种游戏录像比视屏录像保存的文件小很多。
图7是根据本申请实施例的一种断线重连的方法的流程示意图。如图7所示，由于弱网络环境，导致中继服务器(Relay Server)的多个包未被客户端1(1P Client)处理，因而需要客户端1快进处理，客户端1在断 线重新连接之后，会自动从上次断线的最后一个广播包的序列号开始，重新下载所有记录过的数据包，然后重新加速运算整局游戏，最终与客户端2(2P Client)的显示结果一致。
最后要解决的是弱网络环境下的延迟波动，这个问题直接影响游戏画面的忽快忽慢，让游戏玩家难以准确把握输入和响应之间的提前量。可以在客户端处建立一定大小的缓冲区，在收到网络广播包后不立刻通知游戏逻辑代码，而是先放入缓冲区，然后定时将缓冲区的数据包通知给游戏客户端代码。
图8是根据本申请实施例的一致缓存发包的方法的流程示意图。如图8所示，客户端(Client)中的游戏逻辑(Game Logic)向中继服务器(Realy Server)发送操作，中继服务器接收到操作之后，广播收到的操作，客户端在收到操作后不立刻通知游戏逻辑代码，而是先放入缓冲区(Cache)，等累积到固定个数之后，定时将缓冲区的数据包通知给游戏客户端代码。这样客户端代码得到的数据包，就会在一定时间段内速度是比较稳定的。虽然这会增加整体网络数据包的延迟，但是能让所有的网络包的到达速度保持一致，让玩家形成一个稳定的操作手感。
下面对逻辑校验进行介绍。
由于网络游戏一般都要面对外挂和破解的威胁，所以游戏的实时战斗过程，往往也需要由服务器进行合法性验证。该实施例将所有广播给客户端的数据，都同样的广播一份给开发者所设置的游戏服务器(GameServer)，这样游戏服务器就能实时地掌握所有客户端接收到的数据包，从而进行任何自己想要的验证鉴权。当游戏服务器发现有某个客户端作弊，开发者不但可以立刻将有问题的客户端“踢出”本局游戏，而且还可以获得完整的作弊记录，用作日后对作弊客户端的进一步惩罚和预防。同样，游戏服务器也可以利用这个功能，来进行敏感操作的服务器端运算，比如，需要在游戏中掉落战利品，这个操作可以由游戏服务器来完成，然后同样利用广播接口发送给所有客户端，这些掉落的战利品的数据信息。
该实施例的游戏服务器端接口，实际上拥有客户端接口的全部功能，再额外增加了房间管理的能力。
以上功能，用户在使用的时候，需要通过客户端接口和服务器端接口来调用
下面结合另外一种优选的实施例对本申请的技术方案进行说明。
图9是根据本申请实施例的一种服务器端的架构图。如图9所示，该服务器段架构图包括存储系统(Tcaplus)、房间管理服务(RoomMng)、房间服务器(RoomSvr)、接入组件进程(Tconnd)、客户端(Client)、接入开发工具包(LockStepFrame)、游戏服务器(GameSvr)、服务接口(Apollo Service Api)。房间管理服务与服务器接口之间的数据传输协议为传输控制协议，还可以与游戏服务器的数据传输协议为超文本传输协议。
RoomMng：房间管理服务，为GameSvr游戏服务器提供创建房间，销毁房间，查询房间的功能。
RoomSvr：为帧同步房间服务，为同一Room(一次PVP即玩家互相利用游戏资源攻击而形成的互动竞技对局)的玩家提供收集帧数据、组帧、广播帧数据的功能。一个RoomSvr可以同时为多个房间服务。
Tconnd：作为RoomSvr的接入层，为客户端玩家提供UDP接入功能。
LockStepFrame：面向客户端的接入SDK，提供建立连接，发送帧数据，关闭连接等接口。
Apollo Service Api：面向GameSvr的接入SDK，提供创建房间，销毁房间，查询房间接口。
Tcaplus：RoomMng会把创建的房间信息存到Tcaplus中。
在客户端连上游戏服务器GameSvr大厅后，发起例如5V5对战，GameSvr通过调用LockStep Service的接口创建PVP房间，LockStep Service会返回各个成员的RoomID，RoomKey以及房间Url，房间管理服 务GameSvr将此信息返回给客户端，各个游戏客户端都会连到同一个PVP RoomSvr，当对局内玩家全部连上后，开始进入帧同步转发逻辑，也即，收集每个客户端的动作，组成一个完整的帧内容广播给对局内其他玩家。
图10是根据本申请实施例的一种游戏房间操作流程的示意图。如图10所示，客户端登录游戏，发起对战请求，游戏服务器(GameSvr)通过CreatRoom()函数创建房间，房间管理服务(RoomMng)将创建房间的信息向房间服务器(RoomSvr)传输，房间服务器向房间管理服务返回房间信息，房间管理服务将房间信息向游戏服务器传输，客户端从游戏服务器获取房间信息。客户端登录PVP房间，客户端正式对战前进行消息同步，例如，加载进度的同步，也即，加载速度同步，房间服务器广播其他客户端的数据，客户端通知房间服务器准备完毕，房间服务器等待客户端全部准备完成，通知所有客户端战斗开始。客户端向房间服务器发送帧数据，房间服务器等待玩家的帧数据，组帧，向所有客户端广播帧数据。在客户端发生断线的情况下，客户端向房间服务器请求补帧，房间服务器向客户端发送补帧数据，在游戏结束时，客户端退出房间。
表1存储数据结构表
Figure PCTCN2018086327-appb-000001
Figure PCTCN2018086327-appb-000002
表1为本申请实施例的一种存储数据结构表。房间ID，主键的字段名为room_id，类型为uint64；业务ID的字段名为business_id，类型为uint32；房间所属roomsvr进程ID的字段名为process_id，类型为uint32；客户端接入房间的地址的字段名为access_url，类型为string(64)；房间人数的字段名为member_count，类型为uint32；一个member的信息为4字节objectid+16字节memberkey＝20字节2564可以存下128个member信息的字段名为member_info，类型为blob(2564)；房间创建时间戳的字段名为create_time，类型为uint64；最后更新时间戳的字段名为last_update_time，类型为uint64。
下面对房间创建流程进行介绍。
一个房间对应于一次PVP对局，房间存在于RoomSvr中，一个RoomSvr可以支撑多个房间。RoomSvr会定期向所有RoomMng上报自身的信息，包括总共支持多少房间、当前已创建了多少房间等。当GameSvr发起创建房间的命令时，该请求会随机落在一个RoomMng上，RoomMng收到请求后，会综合当前所有RoomSvr的负载情况，选择一个RoomSvr发送创建房间的命令。RoomSvr收到创建房间的命令后，会创建房间，并给房间的每个member分配一个随机key，该Key将用于后续客户端到RoomSvr的消息加解密。
RoomID为int64类型，前32位为RoomSvr进程ID，后32位为进程内自增序列，RoomKey为随机生成的字符串，长度为32。
RoomMng在收到RoomSvr成功创建房间的应答后，会将这个房间的信息写入TCAPLUS，信息包括RoomID，业务ID，成员数，RoomSvr的进程ID，接入地址，各成员的key。
下面对房间销毁进行介绍。
房间销毁的途径包括以下4种：
GameSvr主动销毁房间，这个包括对战正常结束，或者游戏发现有玩家作弊而异常关闭的，消息路径为GameSvr->RoomMng->Tcaplus；
RoomSvr接收到了所有客户端退出房间的消息，而关闭房间，这个是对应正常的PVP战斗结束流程，消息路径为RoomSvr->RoomMng->Tcaplus；
RoomSvr上因为房间若干时间没消息通信而关闭房间，这种主要为防止PVP已经正常结束，但是GameSvr和客户端没有主动调用关闭房间的情况，消息路径为RoomSvr->RoomMng->Tcaplus；
自动扫描工具扫描Tcaplus表中超过2天前建立的房间，将其关闭，这种是为防止RoomSvr重启导致房间信息丢失的情况，消息路径为CleanTool->Tcaplus。
图11是根据本申请实施例的一种消息分发流程的示意图。如图11所示，在对局登录(Login)时，客户端1登录房间服务器(RoomSvr)，房间服务器对局登录会对MemberKey进行校验(Verify)，在校验失败的情况下，回复错误信息。客户端2登录房间服务器。在登录阶段，LockStepSvr对局的状态标记为Login，这个时候LockStepSvr会对客户端Input进行转发，但FrameId标记为0，并且FrameId为0的数据不会在LockStepSvr保留，也就是断线重连上来的客户端不会收到FrameId为0的数据。
客户端1在正式对战前的消息同步，比如加载进度等。
在对局开始时，对局开始的时机为LockStepSvr收到所有客户端的BattleStart请求才开始正式的对局转发。在其他玩家都登录完毕后，开始向服务器(SVR)发送战斗开始请求(BattleStart)，此时FrameId标记为1，表示帧同步正式开始。可能会存在这样的情况，3v3对局，只收到了5个BattleStart请求，出现这种情况，LockStepSvr会触发一个超时机制，如收到第一BattleStart请求之后10秒(具体时间GameSvr指定)，也会启动帧同步流程，此时LockStepSvr状态为LockStep。在向服务器发送战斗开始请求之后，等待其他客户端准备。
房间服务器在等到收到所有客户端的开始(START)命令后，开始向客户端通知(BattleStart Notify)。
客户端1和客户端2向房间服务器输入帧(Frame Input)，房间服务器组帧，得到缓冲(cache)帧数据。房间服务器向客户端1和客户端2发送完整的帧数据(Complete Frame Data)。客户端1和客户端2在接收到房间服务器发送的房间服务器之后，退出登录(LogOut)房间服务器。
可选地，在对局重连时，对局重连分为两种情况，第一种情况是玩家因为网络断线，客户端调用Login接口重新登录，同时调用RequestFrame(LastFrameId)来获取丢失的帧数据。第二种情况是玩家进程退出，房间URL、MemberKey、FrameId等信息丢失，这种情况需要GameSvr去RoomSvr查询获得相关信息然后重新Login，并从第一帧开始同步数据。
在对局结束时，客户端调用Stop接口，LockStep标示该链接为Stop状态，此时将丢弃该客户端的Input输入，并且收到多数客户端的Stop请求之后，房间进入销毁状态。
GameSvr在创建房间的时候会传入帧同步参数，比如，15帧/s，LockStepSvr从发出去第1帧开始对FrameId进行自增策略。在n帧和n+1帧之间，对所有客户端输入进行打包，然后广播给所有在局用户。服务器下发给客户端信息主要包括3部分，ObjectId(客户端的唯一表示)、FrameId(当前帧号)以及客户端的Input信息。
在n帧和n+1帧之间，如果m个客户端input了k个消息，那么LockStepSvr将打包m*k个消息，如果超过了MTU，将部分消息放到下一帧去进行打包。
在n帧和n+1帧之间，如果m个客户端没有input输入，那么LockStepSvr会自增FrameId，同时广播所有客户端，但不打包任何消息。
LockStepSvr和客户端API配合保证使用者接受到的消息一定是帧序号连续的，客户端API如果发现帧序号不连续，会主动请求丢失的帧(LostFrame)，使用者无需关心丢帧问题。
帧同步默认冗余2帧信息，最大冗余3帧信息，根据用户网络环境自适应切换。
客户端通过Tconnd访问RoomSvr，客户端到Tconnd之间采用Udp透传模式，Tconnd上不进行数据加解密，加解密的工作由RommSvr完成。
RoomMng主要功能是收集各个RommSvr的状态，管理房间的创建，具体房间信息是存在Tcaplus中，而不是在RoomMng的内存中，进程Crash后可以立即重启并向RoomSvr拉取信息，迅速恢复服务。
RoomSvr上存有房间的具体信息，以及该房间所有产生的帧数据，进程Crash后，对应房间的信息将丢失，由于PVP一场对局持续时间不会太久，所以影响不大，让业务侧重新创建房间即可。
Tconnd为接入层，无状态，进程重启不影响服务功能。
RoomMng可平行扩展，内存和CPU消耗不会太大，在一个集群里部署两个节点即可。
RoomSvr可平行扩展，根据业务需要可动态扩容。
图12是根据本申请实施例的客户端的登录流程的示意图。如图12所示，游戏客户端(Game Client)需要为战斗游戏创建房间，游戏服务器(Game Server)向服务器系统(LockStep Server)发送请求创建房间的请 求，服务器系统向游戏服务器返回响应请求创建房间的信息列表，游戏客户端向游戏服务器发送进入房间的请求，游戏服务器向游戏客户端发送响应进入房间的请求的结果，游戏客户端登录客户端系统，与服务器系统相连接，如果服务器系统需要客户端系统重新登录，客户端系统向服务器系统发送重新登录请求，服务器系统返回响应重新登录请求的结果(需要说明的是，图12中的序号0至9用于表示各个步骤执行的先后顺序)。
图13是根据本申请实施例的一种开始流程的示意图。如图13所示，游戏客户端1(Game Client1)向客户端系统(LockStep Client)发送广播(SendBroadcast)消息，客户端系统向服务器系统(LockStep Server)发送广播消息，服务器系统向客户端系统发送对广播消息的应答信息，客户端系统向客户端1发送广播消息的应答信息。
游戏客户端N向服务器系统发送广播消息，服务器系统响应广播消息，并向游戏客户端N发送广播消息的应答消息，游戏客户端N在收到第一帧(PopFrame)，即可以认为游戏已经开始，游戏也可以访问HasStarted属性判断对局是否开始(需要说明的是，图13中的序号1至3、1’和2’用于表示各个步骤执行的先后顺序)。
图14是根据本申请实施例的一种帧同步流程的示意图。如图14所示，游戏客户端1向客户端系统发送输入数据，客户端系统向服务器系统发送输入数据，服务器系统将输入数据组帧，并将组帧后的数据包向客户端系统发送，游戏客户端收到第一帧(PopFrame)数据。游戏客户端N向服务器系统发送输入数据，服务器系统向客户端N返回第一帧数据(需要说明的是，图14中的序号1至5、1’和5’用于表示各个步骤执行的先后顺序)。
该实施例的帧同步只有满足以下条件之一才会开始：所有玩家都Ready；LockStep Server超时；满足LockStep Server的其它机制。
帧数据由LockStep Server按照自己的定时器在固定的时间产生，即使没有任何用户输入，也会生成空帧。
客户端会自动检查每个帧同步包的序号，如果出现数据包丢失，则启动TCP的下载通道，向RelayServer去下载缺失的帧，而这个时候PopFrame()接口将不会返回帧数据，直到所有的缺失帧补齐，才按顺序返回完整的帧数据。
图15是根据本申请实施例的一种广播流程的示意图。如图15所示，游戏客户端1发送广播信息(SendBroadcast)，客户端系统向服务器系统发送广播信息，服务器系统向客户端系统返回广播数据，客户端系统向游戏客户端1发送广播数据。
游戏客户端2向服务器系统发送广播消息，服务器系统向游戏客户端2发送广播数据(需要说明的是，图15中的序号1至4、1’和4’用于表示各个步骤执行的先后顺序)。
该实施例的广播通道不依赖于游戏是否开始，只要成功登录之后就可以进行收发数据。广播数据一旦到达客户端的软件开发工具包，就会立刻回调用户定义的收包函数进行处理。
该实施例的数据处理方法的通用性好，可以用于需要帧同步机制的实时同步游戏，也可以用于最简单的网络聊天室应用。在游戏应用中，除了支持帧同步，也支持部分状态同步的同步实现方法，使用起来非常灵活。该实施例可以让没有能力，或者不想自己编写帧同步机制的游戏开发团队，也能很简单的使用帧同步这种技术，来开发自己的游戏。并且使用这种技术，并不需要源代码上的授权，仅仅接入本系统的SDK即可。
该实施例在网络优化方面，集成了很多实时同步玩法游戏所需要的功能，比如，可变的冗余UDP包，用以降低丢包带来的体验下降；自动下载缺失帧和UDP冗余这两项设计，承担起丢包、断线的网络包恢复工作，使得开发者不需要再自行开发相关的网络操作代码，大大降低了开发成本；
该实施例的另外一个突出优点是，可以把网络同步的服务，从一般的游戏服务器集群中分离开来，形成一个可以单独部署和运维的集群。与一 般的游戏引擎提供的广播服务有本质区别的是，这种服务器系统是完全集群化的，也即，可以无限扩充其承载能力，并且也拥有运行时扩容、动态容灾、负载平衡这些集群服务固有的好处。最重要的是，这些好处都不需要游戏开发者做任何开发工作。这让游戏项目可以仅仅是通过接入本系统的云服务，就可以拥有强大的承载能力，这对于游戏项目的运营有非常大的便利性。同时以云的方式，多个游戏项目可以共享同一套网络同步集群，能最大限度减少硬件资源的浪费。
在一些网络游戏中，有一些使用了p2p的数据广播方式，代替从服务器端定时广播。这种方案同样还是需要房间管理、游戏服务器验证等功能，只不过是广播数据的通道变化了而已，这依然是在该实施例的主体设计之内。
图16是根据本申请实施例的一种P2P方式的同步游戏的示意图。如图16所示，多个手机客户端进入房间，向房间管理服务器发送游戏数据，房间管理服务器向游戏服务器发送同步游戏数据，游戏服务器验证同步游戏数据的合法性，其中，多个手机客户端之间的传输为P2P传输同步游戏数据。
另外还有一些方案，采用的接口不是“收取”“发送”形式的函数，而是通过“状态参数”同步的形式来实现。
图17是根据本申请实施例的一种参数同步的接口方法的流程图。如图17所示，游戏状态同步系统、多个手机客户端，其中，多个手机客户端中包括参数A。手机客户端通过参数A向游戏状态同步系统发送参数修改事件，游戏状态同步系统通过参数A接收参数修改事件，多个手机客户端中的其它客户端的参数和发送修改参数事件的手机客户端中的参数看起来是同步的。这种方案实际上，只是把状态参数的修改事件，进行了广播，然后对此事件做了一层包装。这种方案底层还是存在和本系统相同的“收取”、“发送”形式的接口的。
该实施例的服务器系统，需要完成数据广播功能、实时同步游戏状态、 优化网络延迟丢包体验、提供玩家断线重连能力、对局游戏的重播等一系列任务。通过抽象实时对战玩法的共性，统一地完成了上述常见的功能，提供了一套接入即可用的服务器系统，令游戏开发团队，仅需要开发具体游戏的客户端代码，即可快速实现网络实时对战功能，降低了数据处理的开发成本。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。
根据本申请实施例的又一方面，还提供了一种用于实施上述数据处理方法的数据处理装置，应用于服务器。图18是根据本申请实施例的一种数据处理装置的示意图。如图18所示，该装置可以包括：创建单元10、确定单元20和广播单元30。
创建单元10，设置为创建用于执行目标事件的目标场景，其中，目标事件为实时对战类事件。
确定单元20，设置为确定处于目标场景中的多个客户端，其中，多个 客户端用于执行目标事件。
广播单元30，设置为定时向多个客户端广播第一请求，其中，第一请求用于请求多个客户端同步执行第一事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第一事件的第一数据包，目标事件包括第一事件。
需要说明的是，该实施例中的创建单元10可以设置为执行本申请实施例中的步骤S202，该实施例中的确定单元20可以设置为执行本申请实施例中的步骤S204，该实施例中的广播单元30可以设置为执行本申请实施例中的步骤S206。
该实施例由于定时向多个客户端广播第一请求，以使多个客户端同步执行第一事件，达到了通用广播服务器的帧同步广播的目的，从而实现了降低数据处理的开发成本的技术效果，进而解决了相关技术中数据处理的开发成本高的技术问题。
此处需要说明的是，上述单元与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现。其中，硬件环境包括网络环境。
根据本申请实施例的又一方面，还提供了一种用于实施上述数据处理方法的电子装置，应用于服务器或终端。
图19是根据本申请实施例的一种终端的结构框图。如图19所示，该终端可以包括：一个或多个(图中仅示出一个)处理器191、存储器193、以及传输装置195，如图19所示，该终端还可以包括输入输出设备197。
其中，存储器193可用于存储软件程序以及模块，如本申请实施例中的数据处理方法和装置对应的程序指令/模块，处理器191通过运行存储在存储器193内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的数据处理方法。存储器193可包括高速随机存储器，还可以 包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器193可进一步包括相对于处理器191远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
上述的传输装置195用于经由一个网络接收或者发送数据，还可以用于处理器191与存储器193之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置195包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置195为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。
其中，具体地，存储器193用于存储应用程序。
处理器191可以通过传输装置195调用存储器193存储的应用程序，以执行下述步骤：
创建用于执行目标事件的目标场景，其中，目标事件为实时对战类事件；
确定处于目标场景中的多个客户端，其中，多个客户端用于执行目标事件；
定时向多个客户端广播第一请求，其中，第一请求用于请求多个客户端同步执行第一事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第一事件的第一数据包，目标事件包括第一事件。
处理器191还用于执行下述步骤：接收第一数量的客户端发送的第一请求，其中，多个客户端包括第一数量的客户端；在接收到第一请求之后，在第一时间向多个客户端广播第一请求，其中，第一时间与上一次向多个客户端广播第二请求的时间相隔第一预设时间，第二请求用于请求多个客 户端同步执行第二事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第二事件的第二数据包，目标事件包括第二事件。
处理器191还用于执行下述步骤：当第一时间到达时，且未接收到任何多个客户端发送的请求的情况下，向多个客户端广播携带空帧的第一请求。
处理器191还用于执行下述步骤：分别获取前N次向多个客户端广播的请求中所携带的N个数据包，其中，N次与N个数据包一一对应，N为大于等于1的自然数；定时向多个客户端广播携带有N个数据包和第一数据包的第一请求。
处理器191还用于执行下述步骤：在定时向多个客户端广播第一请求之后，记录第一数据包；定时向多个客户端广播第三请求，其中，第三请求用于请求多个客户端同步执行第三事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第三事件的第三数据包，目标事件包括第三事件；记录第三数据包。
处理器191还用于执行下述步骤：在定时向多个客户端广播第一请求之后，在多个客户端中的第一客户端失去连接，且在记录第三数据包之后重新建立连接的情况下，向第一客户端发送第一数据包和第三数据包，其中，第一客户端在失去连接的过程中未接收到第一数据包和第三数据包，多个客户端中的第一客户端失去连接包括：多个客户端中的第一客户端所处的网络断线；或者多个客户端中的第一客户端退出事件执行进程。
处理器191还用于执行下述步骤：在定时向多个客户端广播第一请求之后，在多个客户端中的第一客户端失去连接，且在记录第三数据包之后重新建立连接的情况下，接收客户端发送的第四请求，其中，第四请求用于请求获取第一数据包或第三数据包，第一客户端在失去连接的过程中未接收到第一数据包和第三数据包；响应第四请求，并向第一客户端发送第一数据包或第三数据包。
处理器191还用于执行下述步骤：在定时向多个客户端广播第一请求时，验证第一数据包是否合法；在验证出第一数据包不合法的情况下，禁止发送第一数据包的客户端执行目标事件，和/或记录用于指示第一数据包不合法的信息。
处理器191还用于执行下述步骤：向第一服务器广播第一数据包；通过第一服务器验证第一数据包是否合法。
处理器191还用于执行下述步骤：获取每个客户端的操作信息；将每个客户端的操作信息组合为数据帧；定时向多个客户端广播携带有数据帧的第一请求。
处理器191还用于执行下述步骤：获取多个第二服务器的场景信息，其中，每个第二服务器的场景信息包括用于指示每个第二服务器允许创建的场景和已经创建的场景的信息；接收场景创建请求，并根据多个第二服务器的场景信息确定用于创建目标场景的目标服务器，其中，场景创建请求用于请求创建目标场景；向目标服务器发送创建指令，其中，创建指令用于指示目标服务器创建目标场景；在目标服务器接收到创建指令之后，通过目标服务器创建目标场景。
处理器191还用于执行下述步骤：在确定处于目标场景中的多个客户端之后，对多个客户端的登录信息进行校验；在对至少一个客户端的登录信息校验失败的情况下，发送校验失败信息；在对多个客户端的登录信息校验成功的情况下，将多个客户端发送的数据设置为空帧。
处理器191还用于执行下述步骤：接收多个客户端发送的第五请求，其中，第五请求用于请求开始执行目标事件；响应第五请求，并允许定时向多个客户端广播第一请求。
处理器191还用于执行下述步骤：在未全部接收到多个客户端发送的第五请求的情况下，在第三预设时间允许定时向多个客户端广播第一请求。
采用本申请实施例，提供了一种数据处理的方案。由于定时向多个客 户端广播第一请求，以使多个客户端同步执行第一事件，达到了通用广播服务器的帧同步广播的目的，从而实现了降低数据处理的开发成本的技术效果，进而解决了相关技术中数据处理的开发成本高的技术问题。
可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。
本领域普通技术人员可以理解，图19所示的结构仅为示意，终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile Internet Devices，MID)、PAD等终端设备。图19其并不对上述电子装置的结构造成限定。例如，终端还可包括比图19中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图19所示不同的配置。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(Random Access Memory，RAM)、磁盘或光盘等。
根据本申请的实施例的又一方面，还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行数据处理方法的计算机程序。
可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的计算机程序：
创建用于执行目标事件的目标场景，其中，目标事件为实时对战类事件；
确定处于目标场景中的多个客户端，其中，多个客户端用于执行目标事件；
定时向多个客户端广播第一请求，其中，第一请求用于请求多个客户端同步执行第一事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第一事件的第一数据包，目标事件包括第一事件。
可选地，存储介质还被设置为存储用于执行以下步骤的计算机程序：接收第一数量的客户端发送的第一请求，其中，多个客户端包括第一数量的客户端；在接收到第一请求之后，在第一时间向多个客户端广播第一请求，其中，第一时间与上一次向多个客户端广播第二请求的时间相隔第一预设时间，第二请求用于请求多个客户端同步执行第二事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第二事件的第二数据包，目标事件包括第二事件。
可选地，存储介质还被设置为存储用于执行以下步骤的计算机程序：当第一时间到达时，且未接收到任何多个客户端发送的请求的情况下，向多个客户端广播携带空帧的第一请求。
可选地，存储介质还被设置为存储用于执行以下步骤的计算机程序：分别获取前N次向多个客户端广播的请求中所携带的N个数据包，其中，N次与N个数据包一一对应，N为大于等于1的自然数；定时向多个客户端广播携带有N个数据包和第一数据包的第一请求。
可选地，存储介质还被设置为存储用于执行以下步骤的计算机程序：在定时向多个客户端广播第一请求之后，记录第一数据包；定时向多个客户端广播第三请求，其中，第三请求用于请求多个客户端同步执行第三事件，且携带有由多个客户端中的至少一个客户端发送的用于执行第三事件的第三数据包，目标事件包括第三事件；记录第三数据包。
可选地，存储介质还被设置为存储用于执行以下步骤的计算机程序：在定时向多个客户端广播第一请求之后，在多个客户端中的第一客户端失去连接，且在记录第三数据包之后重新建立连接的情况下，向第一客户端发送第一数据包和第三数据包，其中，第一客户端在失去连接的过程中未接收到第一数据包和第三数据包，多个客户端中的第一客户端失去连接包 括：多个客户端中的第一客户端所处的网络断线；或者多个客户端中的第一客户端退出事件执行进程。
可选地，存储介质还被设置为存储用于执行以下步骤的计算机程序：在定时向多个客户端广播第一请求之后，在多个客户端中的第一客户端失去连接，且在记录第三数据包之后重新建立连接的情况下，接收客户端发送的第四请求，其中，第四请求用于请求获取第一数据包或第三数据包，第一客户端在失去连接的过程中未接收到第一数据包和第三数据包；响应第四请求，并向第一客户端发送第一数据包或第三数据包。
可选地，存储介质还被设置为存储用于执行以下步骤的计算机程序：在定时向多个客户端广播第一请求时，验证第一数据包是否合法；在验证出第一数据包不合法的情况下，禁止发送第一数据包的客户端执行目标事件，和/或记录用于指示第一数据包不合法的信息。
可选地，存储介质还被设置为存储用于执行以下步骤的计算机程序：向第一服务器广播第一数据包；通过第一服务器验证第一数据包是否合法。
可选地，存储介质还被设置为存储用于执行以下步骤的计算机程序：通过调用预设接口创建目标场景；和/或通过预设接口向多个客户端发送目标场景的信息，其中，目标场景的信息包括以下至少之一：目标场景的地址信息；目标场景的键值信息；目标场景的统一资源定位符。
可选地，存储介质还被设置为存储用于执行以下步骤的计算机程序：获取每个客户端的操作信息；将每个客户端的操作信息组合为数据帧；定时向多个客户端广播携带有数据帧的第一请求。
可选地，存储介质还被设置为存储用于执行以下步骤的计算机程序：获取多个第二服务器的场景信息，其中，每个第二服务器的场景信息包括用于指示每个第二服务器允许创建的场景和已经创建的场景的信息；接收场景创建请求，并根据多个第二服务器的场景信息确定用于创建目标场景的目标服务器，其中，场景创建请求用于请求创建目标场景；向目标服务 器发送创建指令，其中，创建指令用于指示目标服务器创建目标场景；在目标服务器接收到创建指令之后，通过目标服务器创建目标场景。
可选地，存储介质还被设置为存储用于执行以下步骤之一的计算机程序：在确定处于目标场景中的多个客户端之后，对多个客户端的登录信息进行校验；在对至少一个客户端的登录信息校验失败的情况下，发送校验失败信息；在对多个客户端的登录信息校验成功的情况下，将多个客户端发送的数据设置为空帧。
可选地，存储介质还被设置为存储用于执行以下步骤之一的计算机程序：接收多个客户端发送的第五请求，其中，第五请求用于请求开始执行目标事件；响应第五请求，并允许定时向多个客户端广播第一请求。
可选地，存储介质还被设置为存储用于执行以下步骤之一的计算机程序：在未全部接收到多个客户端发送的第五请求的情况下，在第三预设时间允许定时向多个客户端广播第一请求。
可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对相关技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施 例所述方法的全部或部分步骤。
在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。
工业实用性
在本申请实施例中，服务器创建用于执行目标事件的目标场景，其中，目标事件为实时对战类事件；服务器确定处于目标场景中的多个客户端，其中，多个客户端用于执行目标事件；服务器定时向多个客户端广播第一请求，其中，第一请求用于请求多个客户端同步执行第一事件，且携带有 由多个客户端中的至少一个客户端发送的用于执行第一事件的第一数据包，目标事件包括第一事件，由于定时向多个客户端广播第一请求，以使多个客户端同步执行第一事件，达到了通用广播服务器的帧同步广播的目的，从而实现了降低数据处理的开发成本的技术效果。

Claims (17)

  1. 一种数据处理方法，包括：
    服务器创建用于执行目标事件的目标场景，其中，所述目标事件为实时对战类事件；
    所述服务器确定处于所述目标场景中的多个客户端，其中，所述多个客户端用于执行所述目标事件；
    所述服务器定时向所述多个客户端广播第一请求，其中，所述第一请求用于请求所述多个客户端同步执行第一事件，且携带有由所述多个客户端中的至少一个客户端发送的用于执行所述第一事件的第一数据包，所述目标事件包括所述第一事件。
  2. 根据权利要求1所述的方法，其中，所述服务器定时向所述多个客户端广播所述第一请求包括：
    所述服务器接收第一数量的客户端发送的所述第一请求，其中，所述多个客户端包括所述第一数量的客户端；
    所述服务器在接收到所述第一请求之后，在第一时间向所述多个客户端广播所述第一请求，其中，所述第一时间与上一次向所述多个客户端广播第二请求的时间相隔第一预设时间，所述第二请求用于请求所述多个客户端同步执行第二事件，且携带有由所述多个客户端中的至少一个客户端发送的用于执行所述第二事件的第二数据包，所述目标事件包括所述第二事件。
  3. 根据权利要求2所述的方法，其中，所述服务器定时向所述多个客户端广播所述第一请求包括：
    当所述第一时间到达时，且未接收到任何所述多个客户端发送的请求的情况下，所述服务器向所述多个客户端广播携带空帧的所述第一请求。
  4. 根据权利要求1所述的方法，其中，所述服务器定时向所述多个客户 端广播所述第一请求包括：
    所述服务器分别获取前N次向所述多个客户端广播的请求中所携带的N个数据包，其中，所述N次与所述N个数据包一一对应，所述N为大于等于1的自然数；
    所述服务器定时向所述多个客户端广播携带有所述N个数据包和所述第一数据包的所述第一请求。
  5. 根据权利要求1所述的方法，其中，在所述服务器定时向所述多个客户端广播所述第一请求之后，所述方法还包括：
    所述服务器记录所述第一数据包；
    所述服务器定时向所述多个客户端广播第三请求，其中，所述第三请求用于请求所述多个客户端同步执行第三事件，且携带有由所述多个客户端中的至少一个客户端发送的用于执行所述第三事件的第三数据包，所述目标事件包括所述第三事件；
    所述服务器记录所述第三数据包。
  6. 根据权利要求5所述的方法，其中，在所述服务器定时向所述多个客户端广播所述第一请求之后，所述方法还包括：
    在所述多个客户端中的第一客户端失去连接，且在记录所述第三数据包之后重新建立连接的情况下，所述服务器向所述第一客户端发送所述第一数据包和所述第三数据包，其中，所述第一客户端在失去连接的过程中未接收到所述第一数据包和所述第三数据包，所述多个客户端中的第一客户端失去连接包括：所述多个客户端中的第一客户端所处的网络断线；或者所述多个客户端中的第一客户端退出事件执行进程。
  7. 根据权利要求5所述的方法，其中，在所述服务器定时向所述多个客户端广播所述第一请求之后，所述方法还包括：
    在所述多个客户端中的第一客户端失去连接，且在记录所述第三数据包之后重新建立连接的情况下，所述服务器接收所述客户端发送 的第四请求，其中，所述第四请求用于请求获取所述第一数据包或所述第三数据包，所述第一客户端在失去连接的过程中未接收到所述第一数据包和所述第三数据包；
    所述服务器响应所述第四请求，并向所述第一客户端发送所述第一数据包或所述第三数据包。
  8. 根据权利要求1所述的方法，其中，在所述服务器定时向所述多个客户端广播所述第一请求时，所述方法还包括：
    所述服务器验证所述第一数据包是否合法；
    在验证出所述第一数据包不合法的情况下，所述服务器禁止发送所述第一数据包的客户端执行所述目标事件，和/或所述服务器记录用于指示所述第一数据包不合法的信息。
  9. 根据权利要求8所述的方法，其中，所述服务器验证所述第一数据包是否合法包括：
    所述服务器向第一服务器广播所述第一数据包；
    所述服务器通过所述第一服务器验证所述第一数据包是否合法。
  10. 根据权利要求1所述的方法，其中，所述服务器定时向所述多个客户端广播所述第一请求包括：
    所述服务器获取每个客户端的操作信息；
    所述服务器将所述每个客户端的操作信息组合为数据帧；
    所述服务器定时向所述多个客户端广播携带有所述数据帧的所述第一请求。
  11. 根据权利要求1所述的方法，其中，所述服务器创建用于执行所述目标事件的所述目标场景包括：
    所述服务器获取多个第二服务器的场景信息，其中，每个第二服务器的场景信息包括用于指示所述每个第二服务器允许创建的场景和已经创建的场景的信息；
    所述服务器接收场景创建请求，并根据所述多个第二服务器的场景信息确定用于创建所述目标场景的目标服务器，其中，所述场景创建请求用于请求创建所述目标场景；
    所述服务器向所述目标服务器发送创建指令，其中，所述创建指令用于指示所述目标服务器创建所述目标场景；
    在所述目标服务器接收到所述创建指令之后，所述服务器通过所述目标服务器创建所述目标场景。
  12. 根据权利要求1所述的方法，其中，在所述服务器确定处于所述目标场景中的所述多个客户端之后，所述方法还包括：
    所述服务器对所述多个客户端的登录信息进行校验；
    在对至少一个客户端的登录信息校验失败的情况下，所述服务器发送校验失败信息；
    在对所述多个客户端的登录信息校验成功的情况下，所述服务器将所述多个客户端发送的数据设置为空帧。
  13. 根据权利要求1所述的方法，其中，所述服务器定时向所述多个客户端广播所述第一请求包括：
    所述服务器接收所述多个客户端发送的第五请求，其中，所述第五请求用于请求开始执行所述目标事件；
    所述服务器响应所述第五请求，并允许定时向所述多个客户端广播所述第一请求。
  14. 根据权利要求13所述的方法，其中，所述服务器允许定时向所述多个客户端广播所述第一请求包括：
    在未全部接收到所述多个客户端发送的所述第五请求的情况下，所述服务器在第三预设时间允许定时向所述多个客户端广播所述第一请求。
  15. 一种数据处理装置，应用于服务器，包括：
    创建单元，设置为创建用于执行目标事件的目标场景，其中，所述目标事件为实时对战类事件；
    确定单元，设置为确定处于所述目标场景中的多个客户端，其中，所述多个客户端用于执行所述目标事件；
    广播单元，设置为定时向所述多个客户端广播第一请求，其中，所述第一请求用于请求所述多个客户端同步执行第一事件，且携带有由所述多个客户端中的至少一个客户端发送的用于执行所述第一事件的第一数据包，所述目标事件包括所述第一事件。
  16. 一种存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至14任一项中所述的方法。
  17. 一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为通过所述计算机程序执行所述权利要求1至14任一项中所述的方法。
PCT/CN2018/086327 2017-06-08 2018-05-10 数据处理方法和装置、存储介质及电子装置 WO2018223800A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710430708.4 2017-06-08
CN201710430708.4A CN107404514A (zh) 2017-06-08 2017-06-08 数据处理方法和装置

Publications (1)

Publication Number Publication Date
WO2018223800A1 true WO2018223800A1 (zh) 2018-12-13

Family

ID=60405120

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/086327 WO2018223800A1 (zh) 2017-06-08 2018-05-10 数据处理方法和装置、存储介质及电子装置

Country Status (2)

Country Link
CN (1) CN107404514A (zh)
WO (1) WO2018223800A1 (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111414553A (zh) * 2020-02-26 2020-07-14 中国平安人寿保险股份有限公司 数据处理的系统、方法及存储介质
CN111488536A (zh) * 2019-01-25 2020-08-04 阿里巴巴集团控股有限公司 图片显示方法、装置与系统
CN111917852A (zh) * 2020-07-23 2020-11-10 上海珀立信息科技有限公司 基于Unity的多人网络同步系统及开发方法
CN112231114A (zh) * 2020-09-22 2021-01-15 深圳云天励飞技术股份有限公司 一种事件处理方法及相关设备
CN113568936A (zh) * 2021-07-30 2021-10-29 多点生活(成都)科技有限公司 实时流数据存储方法、装置、终端设备
CN115134613A (zh) * 2021-03-29 2022-09-30 武汉斗鱼网络科技有限公司 一种直播间信息的获取方法及相关装置
CN115296945A (zh) * 2022-06-28 2022-11-04 青岛海尔科技有限公司 设备的控制方法、系统和装置、存储介质及电子装置

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107404514A (zh) * 2017-06-08 2017-11-28 腾讯科技（深圳）有限公司 数据处理方法和装置
CN108057241A (zh) * 2017-12-12 2018-05-22 苏州蜗牛数字科技股份有限公司 一种竞技类型游戏服务器系统及其交互方法
CN108379833A (zh) * 2018-03-05 2018-08-10 苏州蜗牛数字科技股份有限公司 基于对等计算的针对多用户场景的游戏交互方法及系统
CN110392077A (zh) * 2018-04-20 2019-10-29 杭州游络科技有限公司 一种客户端与服务端可交互的游戏服务器引擎及交互方法
CN108939537A (zh) * 2018-06-29 2018-12-07 苏州蜗牛数字科技股份有限公司 游戏数据处理方法、游戏服务端及游戏客户端
CN109040208B (zh) * 2018-07-18 2021-06-01 广州多益网络股份有限公司 基于多客户端交互的数据同步方法、服务器、系统及介质
CN109271158B (zh) * 2018-07-25 2022-01-11 深圳点猫科技有限公司 一种基于图形化编程平台实现同步云变量的方法及其系统
CN110876852B (zh) * 2018-09-06 2023-09-26 深圳市贰陆陆科技有限公司 微服务的网络游戏数据处理方法及系统
CN109639383A (zh) * 2018-12-24 2019-04-16 苏州蜗牛数字科技股份有限公司 一种实现分布式帧同步服务器群的方法和系统
CN109714328B (zh) * 2018-12-24 2021-08-10 网易（杭州）网络有限公司 游戏集群的容量调整方法和装置
CN109688225B (zh) * 2019-01-08 2021-11-16 网易（杭州）网络有限公司 一种通信方法及装置
CN110138721B (zh) * 2019-03-22 2021-06-29 福建省天奕网络科技有限公司 解耦游戏服务和战斗服务的方法、存储介质
CN111080840B (zh) * 2019-12-04 2022-02-18 中国直升机设计研究所 一种直升机飞控系统数据发送及复现方法
CN113784205B (zh) * 2020-06-10 2023-07-18 腾讯科技（上海）有限公司 审核文件的生成方法、装置以及计算机存储介质
CN111953782A (zh) * 2020-08-14 2020-11-17 上海曼恒数字技术股份有限公司 一种多通道数据的同步方法、装置、介质及设备
CN112787995B (zh) * 2020-12-25 2023-01-10 珠海西山居数字科技有限公司 一种游戏交互方法及系统
CN112999661A (zh) * 2021-03-24 2021-06-22 广州虎牙科技有限公司 一种游戏作弊识别的方法及装置
CN113031874B (zh) * 2021-03-26 2022-05-13 网易（杭州）网络有限公司 基于Kubernetes集群的缓存处理方法、装置、设备及存储介质
CN113746931B (zh) * 2021-09-10 2022-11-22 联想(北京)有限公司 数据同步方法及装置
CN115225623B (zh) * 2022-07-20 2023-08-29 贵阳语玩科技有限公司 基于Unity引擎的网络图片加载方法、装置及介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103701918A (zh) * 2013-12-31 2014-04-02 北京像素软件科技股份有限公司 客户端和服务器同步方法和装置
KR20140094423A (ko) * 2013-01-22 2014-07-30 주식회사 넥슨코리아 게임서버 기준에 의한 로컬 클라이언트와 리모트 클라이언트에서의 프레임 동기화 방법 및 그 시스템
CN106375314A (zh) * 2016-08-31 2017-02-01 腾讯科技（深圳）有限公司 一种游戏同步方法、游戏客户端及游戏服务器
CN107404514A (zh) * 2017-06-08 2017-11-28 腾讯科技（深圳）有限公司 数据处理方法和装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106034129B (zh) * 2015-03-18 2019-04-12 广州四三九九信息科技有限公司 一种用于游戏同步的fbsg方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140094423A (ko) * 2013-01-22 2014-07-30 주식회사 넥슨코리아 게임서버 기준에 의한 로컬 클라이언트와 리모트 클라이언트에서의 프레임 동기화 방법 및 그 시스템
CN103701918A (zh) * 2013-12-31 2014-04-02 北京像素软件科技股份有限公司 客户端和服务器同步方法和装置
CN106375314A (zh) * 2016-08-31 2017-02-01 腾讯科技（深圳）有限公司 一种游戏同步方法、游戏客户端及游戏服务器
CN107404514A (zh) * 2017-06-08 2017-11-28 腾讯科技（深圳）有限公司 数据处理方法和装置

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ENUMA: "Frame Synchronization in Unity3D RTS Game", TENCENT GAD, 17 April 2017 (2017-04-17) *
WADEHAN, GAD: "Development Foundation of Frame Synchronization Game", TENCENT GAD, 8 September 2016 (2016-09-08) *
YOUXITUOLUO: "Best Practice of Real-Time Battle Network Game Based on Frame Synchronization", SOHU, 8 December 2016 (2016-12-08) *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111488536A (zh) * 2019-01-25 2020-08-04 阿里巴巴集团控股有限公司 图片显示方法、装置与系统
CN111488536B (zh) * 2019-01-25 2023-09-15 阿里巴巴集团控股有限公司 图片显示方法、装置与系统
CN111414553A (zh) * 2020-02-26 2020-07-14 中国平安人寿保险股份有限公司 数据处理的系统、方法及存储介质
CN111414553B (zh) * 2020-02-26 2024-09-24 中国平安人寿保险股份有限公司 数据处理的系统、方法及存储介质
CN111917852A (zh) * 2020-07-23 2020-11-10 上海珀立信息科技有限公司 基于Unity的多人网络同步系统及开发方法
CN112231114A (zh) * 2020-09-22 2021-01-15 深圳云天励飞技术股份有限公司 一种事件处理方法及相关设备
CN115134613A (zh) * 2021-03-29 2022-09-30 武汉斗鱼网络科技有限公司 一种直播间信息的获取方法及相关装置
CN113568936A (zh) * 2021-07-30 2021-10-29 多点生活(成都)科技有限公司 实时流数据存储方法、装置、终端设备
CN113568936B (zh) * 2021-07-30 2023-06-13 多点生活(成都)科技有限公司 实时流数据存储方法、装置、终端设备
CN115296945A (zh) * 2022-06-28 2022-11-04 青岛海尔科技有限公司 设备的控制方法、系统和装置、存储介质及电子装置
CN115296945B (zh) * 2022-06-28 2024-03-22 青岛海尔科技有限公司 设备的控制方法、系统和装置、存储介质及电子装置

Also Published As

Publication number Publication date
CN107404514A (zh) 2017-11-28

Similar Documents

Publication Publication Date Title
WO2018223800A1 (zh) 数据处理方法和装置、存储介质及电子装置
US11992769B2 (en) Distributed ledger tracking of event data
JP2020528314A (ja) ゲームコンテンツの同期表示に関する方法、装置および記憶媒体
CA2514578C (en) System and method for interactive on-line gaming
RU2503998C2 (ru) Хостинг и широковещательная передача виртуальных событий с использованием потоковой передачи интерактивного видео
RU2507568C2 (ru) Система для ускорения доставки веб-страницы
CN109692480B (zh) 一种网络游戏内观战方法和装置
US20040242321A1 (en) Cheater detection in a multi-player gaming environment
JP7308964B2 (ja) トランザクショナルメモリ同期
TW201119399A (en) System and method for encoding video using a selected tile and tile rotation pattern
Chan et al. Hydra: a massively-multiplayer peer-to-peer architecture for the game developer
TW201041401A (en) System and method for multi-stream video compression
TW200952495A (en) Apparatus for combining aplurality of views of real-time streaming interactive video
TW201231133A (en) System and method for capturing text for an online application
TW201119403A (en) System and method for compressing video based on latency measurements and other feedback
TW201119400A (en) System and method for selecting a video encoding format based on feedback data
TW201119402A (en) System and method for utilizing forward error correction with video compression
TW200939789A (en) Method for user session transitioning among streaming interactive video servers
CN114244602B (zh) 多用户在线的网络服务系统、方法、装置及介质
Saldana et al. QoE and latency issues in networked games
JP2001170360A (ja) 対戦ゲーム観戦システム
CN106101146B (zh) 基于分块格式进行Flash对等网络直播的方法及系统
Bryant et al. An evaluation of videogame network architecture performance and security
CN113274727A (zh) 直播交互方法、装置和存储介质及电子设备
Liu et al. DaCAP-a distributed Anti-Cheating peer to peer architecture for massive multiplayer on-line role playing game

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18813172

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18813172

Country of ref document: EP

Kind code of ref document: A1