WO2020034758A1 - 多通道数据传输方法及装置 - Google Patents

多通道数据传输方法及装置 Download PDF

Info

Publication number
WO2020034758A1
WO2020034758A1 PCT/CN2019/092467 CN2019092467W WO2020034758A1 WO 2020034758 A1 WO2020034758 A1 WO 2020034758A1 CN 2019092467 W CN2019092467 W CN 2019092467W WO 2020034758 A1 WO2020034758 A1 WO 2020034758A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
uplink
channel
target service
data packets
Prior art date
Application number
PCT/CN2019/092467
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 腾讯科技(深圳)有限公司
Priority to JP2021510518A priority Critical patent/JP7174834B2/ja
Priority to EP19850324.5A priority patent/EP3758412B1/en
Publication of WO2020034758A1 publication Critical patent/WO2020034758A1/zh
Priority to US17/017,531 priority patent/US11350318B2/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0027Control or signalling for completing the hand-off for data sessions of end-to-end connection for a plurality of data sessions of end-to-end connections, e.g. multi-call or multi-bearer end-to-end data connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/15Setup of multiple wireless link connections
    • H04W76/16Involving different core network technologies, e.g. a packet-switched [PS] bearer in combination with a circuit-switched [CS] bearer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath
    • H04L45/245Link aggregation, e.g. trunking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/34Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/563Data redirection of data network streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14Multichannel or multilink protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10Small scale networks; Flat hierarchical networks
    • H04W84/12WLAN [Wireless Local Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • H04W88/06Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Definitions

  • This application relates to the field of computer technology, and in particular, to data transmission technology.
  • transmitting data over the WiFi channel has the advantage of low latency, but the WiFi channel is unstable, and it is prone to channel interference, co-channel interference, and poor signal strength, which leads to high delay or packet loss from the terminal to the WiFi hotspot. . While cellular networks (such as 4G) are relatively stable, the latency will be higher than WiFi.
  • this single-channel packet sending scheme in order to improve the game data transmission effect, there is a preferred single-channel packet sending scheme that supports WiFi and 4G channels, that is, when the WiFi signal becomes poor, the 4G channel is used to send packets.
  • this single-channel packet sending scheme has at least the following disadvantages:
  • the operation of converting 4G channel transmission is only started when the WiFi network has deteriorated, which is a remedy after the fact. At this time, the user experience has been damaged.
  • the data can only be switched from the worse one to the better one. For example, when the WiFi is degraded, some data packets are sent through the 4G channel, but it cannot be avoided when the WiFi or 4G network is shaking Packet loss and high latency conditions.
  • the purpose of the embodiments of the present application is to provide a multi-channel data transmission method and device, a computer-readable medium, and an electronic device, so as to overcome problems such as network stalls, packet loss, and high delay in the data transmission process of the related technology.
  • a multi-channel data transmission method which is applied to a proxy server and includes: receiving a plurality of uplink data packets in parallel through a multi-channel; parsing the plurality of uplink data packets to obtain a plurality of target service data packets and Multiple uplink headers; performing deduplication processing on the multiple target service data packets according to the multiple uplink headers; sending the target service data packets retained after deduplication processing to the target service server; wherein each uplink header includes each The packet sequence number of the upstream data packet.
  • the performing deduplication processing on the multiple target service data packets according to the multiple uplink packet headers includes: if a packet sequence number of the uplink data packet and a packet in a sequence number queue If the sequence numbers are not the same, the packet sequence number of the uplink data packet is added to the sequence number queue, and the corresponding target service data packet is retained; if the packet sequence number of the uplink data packet is the same as any of the packet sequence numbers in the sequence queue, it is discarded The corresponding target business packet.
  • each uplink header further includes a channel identifier and channel information of each uplink data packet; the method further includes: judging a channel type of the uplink data packet according to the channel identifier; If the packet serial number is greater than the maximum packet receiving serial number of the channel of the corresponding channel type, and the corresponding channel information is inconsistent with the channel information stored in the corresponding channel type, the channel information of the corresponding channel type is updated.
  • the method further includes: receiving a reply data packet generated by the target service server in response to the target service data packet; and separately sending the reply data packet according to the latest channel information of each channel type. Encapsulate corresponding downlink headers to generate multiple downlink data packets; and send the multiple downlink data packets to a service client in parallel through the multi-channel.
  • a multi-channel data transmission method applied to a service client including: obtaining a target service data packet; encapsulating the target service data packet with an uplink header separately to form a plurality of uplink data packets; The multiple uplink data packets are sent to the proxy server in parallel in multiple channels; wherein each uplink packet header includes a packet sequence number of each uplink data packet.
  • the method further includes: receiving multiple downlink data packets generated in response to the target service data packet in parallel through the multi-channel; parsing the multiple downlink data packets to obtain multiple replies. A data packet and multiple downlink headers; and performing deduplication processing on the multiple reply data packets according to the multiple downlink headers.
  • a multi-channel data transmission device including: an uplink data receiving module configured to receive a plurality of uplink data packets in parallel through a multi-channel; an uplink data parsing module configured to parse the plurality of uplink data The packet obtains multiple target service data packets and multiple uplink headers.
  • the uplink data deduplication module is configured to perform deduplication processing on the multiple target service data packets according to the multiple uplink headers.
  • the uplink data forwarding module is configured to The target service data packet retained after deduplication is sent to the target service server; wherein each uplink packet header includes a packet sequence number of each uplink data packet.
  • a multi-channel data transmission device including: a target data acquisition module configured to acquire a target service data packet; and an uplink header encapsulation module configured to encapsulate the target service data packet with an upstream header, respectively, Forming multiple uplink data packets; an uplink data sending module configured to send the multiple uplink data packets to a proxy server in parallel through multiple channels; wherein each uplink packet header includes a packet sequence number of each uplink data packet.
  • a multi-channel data transmission system including: a service client configured to obtain a target service data packet, and encapsulating the target service data packet with an uplink header, forming a plurality of uplink data packets and sending the same.
  • a proxy server configured to receive the plurality of uplink data packets in parallel through multiple channels, parse the plurality of uplink data packets to obtain a plurality of target service data packets and a plurality of uplink headers, and Multiple target service data packets are deduplicated, and the target service data packets retained after deduplication processing are sent to the target service server.
  • the proxy server is further configured to receive a reply data packet generated by the target service server in response to the target service data packet, and send the response data packet to the channel information according to the latest channel information.
  • the reply data packet encapsulates respective downlink headers, generates multiple downlink data packets, and sends them;
  • the service client is further configured to receive the multiple downlink data packets in parallel through the multi-channel, and parse the multiple downlink data The packet obtains multiple reply data packets and multiple downlink headers, and performs deduplication processing on the multiple reply data packets according to the multiple downlink headers.
  • a computer-readable medium having stored thereon a computer program, which when executed by a processor implements a method as described in any of the above embodiments.
  • an electronic device including: one or more processors; a storage device configured to store one or more computer programs, and when the one or more computer programs are stored by the one or more computers When the two processors execute, the one or more processors are caused to implement the method according to any one of the foregoing embodiments.
  • multiple uplink data packets are received in parallel through multiple channels; and multiple target service data packets and multiple uplink headers are obtained by parsing the multiple uplink data packets; then, Deduplication processing is performed on multiple target service data packets according to multiple uplink headers; thereafter, the target service data packets retained after deduplication processing are sent to the target service server; wherein each uplink header includes a packet sequence number of each uplink data packet.
  • the uplink service data packets received in parallel are deduplicated and then forwarded to the target service server to target the service.
  • the server shields network changes to ensure that the target business server is unaware of changes in different network environments and does not affect the operation of the target business server.
  • FIG. 1 shows a schematic diagram of an exemplary system architecture to which a multi-channel data transmission method or a multi-channel data transmission device of an embodiment of the present application can be applied;
  • FIG. 3 schematically illustrates a flowchart of a multi-channel data transmission method according to an embodiment of the present application
  • FIG. 5 schematically illustrates a schematic diagram of a multi-channel data transmission system according to an embodiment of the present application
  • FIG. 6 schematically illustrates a schematic diagram of a multi-channel data transmission system according to another embodiment of the present application.
  • FIG. 7 schematically illustrates an overall architecture diagram of a multi-channel data transmission method according to an embodiment of the present application
  • FIG. 8 schematically illustrates a schematic diagram of a client APP sending uplink data packets in multiple channels according to an embodiment of the present application
  • FIG. 9 schematically illustrates a schematic diagram of a client APP receiving downlink data packets in multiple channels according to an embodiment of the present application
  • FIG. 10 schematically illustrates a flowchart of a data packet deduplication method according to an embodiment of the present application
  • FIG. 11 schematically shows an example of a method for deduplication based on the data packet shown in FIG. 10;
  • FIG. 12 schematically illustrates a flowchart of a data packet deduplication method according to another embodiment of the present application.
  • FIG. 13 schematically illustrates a schematic diagram of a load balancing server according to an embodiment of the present application
  • FIG. 15 schematically illustrates a schematic diagram of a proxy service mapping module of a load balancing server according to an embodiment of the present application
  • FIG. 16 schematically illustrates a schematic diagram of a proxy service mapping module of a load balancing server according to another embodiment of the present application
  • FIG. 17 schematically illustrates a schematic diagram of a proxy service mapping module of a load balancing server according to still another embodiment of the present application
  • FIG. 18 schematically illustrates a proxy service mapping module of a load balancing server according to still another embodiment of the present application.
  • FIG. 19 schematically illustrates a logic sequence diagram of a proxy server according to an embodiment of the present application.
  • FIG. 20 schematically illustrates a schematic diagram of a proxy server sending downlink data packets in multiple channels according to an embodiment of the present application
  • FIG. 21 schematically illustrates a block diagram of a multi-channel data transmission device according to an embodiment of the present application.
  • FIG. 22 schematically illustrates a block diagram of a multi-channel data transmission device according to another embodiment of the present application.
  • FIG. 1 shows a schematic diagram of an exemplary system architecture 100 to which a multi-channel data transmission method or a multi-channel data transmission device of an embodiment of the present application can be applied.
  • the system architecture 100 may include any one or more of terminal devices 101, 102, and 103, a network 104, and a server 105.
  • the network 104 is a medium for providing a communication link between the terminal devices 101, 102, 103 and the server 105.
  • the network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, and so on.
  • the numbers of terminal devices, networks, and servers in FIG. 1 are merely exemplary. According to implementation needs, there can be any number of terminal devices, networks, and servers.
  • the server 105 may be a server cluster composed of multiple servers.
  • the user can use the terminal devices 101, 102, 103 to interact with the server 105 through the network 104 to receive or send messages and the like.
  • the terminal devices 101, 102, 103 may be various electronic devices with data transmission functions, including but not limited to smart phones, tablet computers, portable computers and desktop computers, smart chat robots, and so on.
  • the server 105 may be a server providing related services.
  • the user uses the terminal device 103 (also may be the terminal device 101 or 102) to send a request for acquiring game-related information and / or resources to the server 105; the server 105 may request the information related to the game-related information and / or resources received by the server 105, Correspondingly, game related information and / or resources are obtained, and the game related information and / or resources are fed back to the terminal device 103, so that the terminal device 103 can display the game related information and / or resources it receives.
  • the user sends the game operation instruction to the server 105 by using the terminal device 103 (may also be the terminal device 101 or 102); the server 105 may, based on the game operation instruction received by it, respond accordingly
  • the execution result of the game operation instruction is returned to the terminal device 103, and the terminal device 103 displays the execution result of the game operation instruction received by the terminal device 103 accordingly.
  • FIG. 2 is a schematic structural diagram of an electronic device suitable for implementing the embodiments of the present application.
  • the computer system 200 includes a central processing unit (CPU) 201, which can be loaded into a random access memory (RAM) 203 according to a program stored in a read-only memory (ROM) 202 or a program loaded from a storage section 208. Instead, perform various appropriate actions and processes.
  • RAM 203 various programs and data required for system operation are also stored.
  • the CPU 201, the ROM 202, and the RAM 203 are connected to each other through a bus 204.
  • An input / output (I / O) interface 205 is also connected to the bus 204.
  • the following components are connected to the I / O interface 205: an input portion 206 including a keyboard, a mouse, and the like; an output portion 207 including a cathode ray tube (CRT), a liquid crystal display (LCD), and the speaker; a storage portion 208 including a hard disk and the like; a communication section 209 including a network interface card such as a LAN card, a modem, and the like.
  • the communication section 209 performs communication processing via a network such as the Internet.
  • the driver 210 is also connected to the I / O interface 205 as needed.
  • a removable medium 211 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 210 as needed, so that a computer program read therefrom is installed into the storage section 208 as needed.
  • a process described below with reference to a flowchart may be implemented as a computer software program.
  • embodiments of the present application include a computer program product including a computer program borne on a computer-readable medium, the computer program containing program code for performing a method shown in a flowchart.
  • the computer program may be downloaded and installed from a network through the communication section 209, and / or installed from a removable medium 211.
  • CPU central processing unit
  • the computer-readable medium shown in the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the foregoing.
  • the computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable Programming read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the foregoing.
  • a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in combination with an instruction execution system, apparatus, or device.
  • a computer-readable signal medium may include a data signal that is included in baseband or propagated as part of a carrier wave, and which carries computer-readable program code. Such a propagated data signal may take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing.
  • the computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, and the computer-readable medium may be transmitted, transmitted, or transmitted for use by or in connection with an instruction execution system, apparatus, or device. program.
  • Program code embodied on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
  • each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, which contains one or more of the logic functions used to implement the specified logic.
  • Executable instructions may also occur in a different order than those marked in the drawings. For example, two successively represented boxes may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved.
  • each block in the block diagram or flowchart, and combinations of blocks in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with A combination of dedicated hardware and computer instructions.
  • the modules and / or units described in the embodiments of the present application may be implemented by software or hardware.
  • the described modules and / or units may also be provided in a processor.
  • the names of these modules and / or units do not, in some cases, constitute a limitation on the modules and / or units themselves.
  • the present application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or may exist alone without being assembled into the device.
  • the computer-readable medium carries one or more programs, and when the one or more programs are executed by one of the electronic devices, the electronic device is caused to implement a method as described in the following embodiments. For example, the electronic device may implement the steps shown in any one of the embodiments shown in FIG. 3 to FIG. 20.
  • FIG. 3 schematically illustrates a flowchart of a multi-channel data transmission method according to an embodiment of the present application.
  • the multi-channel data transmission method provided by the embodiment of the present application may include the following steps.
  • the method provided in the embodiment of the present application may be executed by a proxy server, for example, but the present application is not limited thereto.
  • step S310 a plurality of uplink data packets are received in parallel through a plurality of channels.
  • the number and types of channels are not limited, and the number of channels can be determined according to the number of communication channels that can be supported between the client and the proxy server.
  • the number of channels can include WiFi channels, 3G / 4G / At least two of 5G channels and wired channels.
  • each uplink data packet may include an uplink header and a target service data packet.
  • the uplink packet header may further include an uplink internal communication packet header and an uplink channel header; and the uplink internal communication packet header may include a service client address that sends the uplink data packet to a proxy server.
  • step S320 the plurality of uplink data packets are parsed to obtain a plurality of target service data packets and a plurality of uplink headers.
  • an uplink header in each uplink data packet is removed from the uplink data packet to obtain a target service data packet.
  • step S330 deduplication processing is performed on the multiple target service data packets according to the multiple uplink packet headers.
  • Each uplink packet header includes a packet sequence number of each uplink data packet.
  • the first threshold recvThred 10
  • the uplink data packet with the packet sequence number 5 is discarded at this time.
  • the first threshold recvThred is 10
  • MaxSeqno of the client is 20
  • the currently received uplink packet sequence number curSeqno 15
  • the unreceived packet set at this time includes the packet sequence number 15, then the uplink data packet with the packet sequence number 15 is retained, and the packet sequence number 15 is deleted from the unreceived packet set.
  • performing the deduplication processing on the multiple target service data packets according to the multiple uplink headers may include: if the packet sequence number of the uplink data packet is different from the packet sequence number in the sequence queue , Add the packet sequence number of the uplink data packet to the sequence number queue and retain the corresponding target service data packet; if the packet sequence number of the uplink data packet is the same as any of the packet sequence numbers in the sequence queue, discard the corresponding target service data package.
  • the method may further include: judging the channel type of the uplink data packet according to the channel identifier; if the packet sequence number of the uplink data packet is greater than the channel maximum packet receiving sequence number of the corresponding channel type, and the corresponding channel information and the corresponding channel If the channel information of the type is not consistent, the channel information of the corresponding channel type is updated.
  • step S340 the target service data packet retained after deduplication processing is sent to the target service server.
  • the method may further include: receiving a reply data packet generated by the target service server in response to the target service data packet; and encapsulating the reply data packet according to the latest channel information of each channel type.
  • the downlink packet header corresponds to the downlink packet header; multiple downlink data packets are generated; and the multiple downlink data packets are sent to a service client in parallel through the multi-channel.
  • the multi-channel data transmission method receives multiple uplink data packets in parallel through the multi-channel; parses the multiple uplink data packets to obtain multiple target service data packets and multiple uplink headers; and then, according to the multiple uplink headers Deduplicate multiple target service data packets; then send the target service data packets retained after deduplication processing to the target service server; where each upstream packet header includes the packet sequence number of each upstream data packet.
  • Channels receive packets at the same time, which can ensure the stability and effectiveness of the transmission of the target service data packets.
  • the upstream service data packets received in parallel are aggregated and deduplicated and then forwarded to the target service server, which shields the target service server from network changes.
  • the target business server is not aware of changes in different network environments, and does not affect the operation of the target business server.
  • FIG. 4 schematically illustrates a flowchart of a multi-channel data transmission method according to another embodiment of the present application.
  • the method provided in the embodiment of the present application may be executed by a service client, but the present application is not limited thereto.
  • the multi-channel data transmission method provided by the embodiment of the present application may include the following steps.
  • step S410 a target service data packet is obtained.
  • the obtaining a target service data packet may include: controlling a server according to a service configuration request, obtaining target service server information; setting a filtering policy according to the target service server information; and intercepting all the services according to the filtering policy.
  • the target business data packet is described.
  • control server is a cloud control server
  • target service server is a game server
  • target service data packet is a game data packet
  • step S420 the target service data packet is respectively encapsulated with an uplink header to form a plurality of uplink data packets.
  • Each uplink packet header may include a packet sequence number of each uplink data packet.
  • step S430 the multiple uplink data packets are sent to the proxy server in parallel through multiple channels.
  • the method may further include: receiving a plurality of downlink data packets generated in response to the target service data packet in parallel through the multi-channel; parsing the plurality of downlink data packets to obtain a plurality of reply data A packet and multiple downlink headers; and performing deduplication processing on the multiple reply data packets according to the multiple downlink headers.
  • FIG. 5 schematically illustrates a schematic diagram of a multi-channel data transmission system according to an embodiment of the present application.
  • the multi-channel data transmission system 500 may include a service client 510 and a proxy server 520.
  • the service client 510 and the proxy server 520 may pass through multiple channels, for example, may pass through channel 1 and channel. 2 to channel n (where n is a positive integer greater than or equal to 2) for parallel data transmission.
  • the service client 510 may be configured to obtain a target service data packet, encapsulate the target service data packet with an uplink header, form multiple uplink data packets, and send the uplink data packets.
  • the proxy server 520 may be configured to receive the plurality of uplink data packets in parallel through multiple channels, parse the plurality of uplink data packets to obtain a plurality of target service data packets and a plurality of uplink headers, and The multiple target service data packets are deduplicated, and the target service data packets retained after the deduplication processing are sent to the target service server 530.
  • the proxy server 520 may be further configured to receive a response data packet generated by the target service server 530 in response to the target service data packet, and respectively encapsulate the response data packet according to the latest channel information of each channel type.
  • a downlink packet header that generates multiple downlink data packets and sends them;
  • the service client 510 may also be configured to receive the multiple downlink data packets in parallel through the multi-channel, and parse the multiple downlink data packets to obtain multiple reply data packets and A plurality of downlink headers, and perform deduplication processing on the plurality of reply data packets according to the plurality of downlink headers.
  • FIG. 6 schematically illustrates a schematic diagram of a multi-channel data transmission system according to another embodiment of the present application.
  • the multi-channel data transmission system 600 may include a service client 610, a load balancing server 620, and a proxy server 630.
  • a service client 610 and the proxy server 630 reference may be made to the service client 510 and the proxy server 520 in the embodiment of FIG. 5 described above, and details are not described herein again.
  • the multi-channel data transmission system 600 provided by the embodiment of the present application may further include a load balancing server 620.
  • the load balancing server 620 may be configured to receive the plurality of uplink data packets in parallel through the multi-channel, and determine a proxy server of the plurality of uplink data packets according to the uplink packet header, and pass the plurality of uplink data packets through the proxy server.
  • the multiple channels are sent to the proxy server 630 in parallel.
  • the method may further include: after the proxy server 630 performs deduplication processing on the multiple uplink data packets, and then sends the deduplicated target service data packet to the target service server 640.
  • the proxy server 630 may process the reply data packet returned by the target service server 640 in response to the received target service data packet, generate multiple downlink data packets, and send multiple downlink data packets in parallel through channel 1 to channel n to
  • the load balancing server 620 sends the plurality of downlink data packets to the service client 610 in parallel through the channel 1 to the channel n through the load balancing server 620.
  • FIG. 7 schematically illustrates an overall architecture diagram of a multi-channel data transmission method according to an embodiment of the present application.
  • the method provided in the embodiments of the present application can implement three or more channels.
  • the dual-channel technology architecture shown in FIG. 7 provides a method for simultaneous packet sending based on WiFi and 4G networks.
  • the method provided in the embodiment of the present application can be applied to a client SDK (Software Development Kit) or software development kit.
  • Client APP application, application
  • the dual-channel client logic can include the following steps.
  • the game client 711 and the client APP 713 are started on the client 710 (such as a mobile client, but not limited thereto, and may be any type of terminal device).
  • the client APP 713 After opening the client APP 713, the client APP 713 creates a virtual network card 7131, and establishes two threads to bind the WiFi channel and the 4G channel.
  • the client APP 713 may send a request to the cloud control server 720 according to the corresponding game service configuration, and the cloud control server 720 sends the game server IP to the client APP 713 according to the request.
  • the client APP 713 sets an iptables filtering policy according to the game server IP, and intercepts the game data packet of the game client 711 from the real network card 712 and forwards it to the virtual network card 7131. This is because the mobile phone client may also have many other business data packets that are not game data packets at the same time.
  • only the configured game data packets may be sent through the dual channel, and those other business data that are not game data packets Packets can still be sent and received using a single channel, which can reduce the amount of network traffic consumed.
  • which game server or which game data packets need to be sent and received through dual channels can be pre-configured and stored in the cloud control server 720.
  • the client APP 713 only intercepts game data packets that need to be sent by dual channels and forwards them to the virtual network card 7131 .
  • the client APP 713 after the client APP 713 receives the game data packet from the virtual network card 7131, it encapsulates the uplink channel header through the uplink processing module 7132 to form two uplink data packets, and passes the two uplink data packets through WiFi respectively. And 4G are sent to the load balancing server 731 and the load balancing server 732.
  • the header of the encapsulated uplink channel may include the following information.
  • the default WiFi channel is the main channel. If the channel number of the WiFi channel is marked as 0, the main channel identifier is 0. Accordingly, the channel identifier is 0 indicating that the channel type of the current uplink data packet is the WiFi channel, and the channel identifier is 1 for The channel type of the current uplink data packet is 4G channel.
  • the unique clientkey of the client can be obtained using the hash32 algorithm.
  • the WiFi channel and the 4G channel belong to different operators, and the WiFi channel is the main channel, the operator ID of the main channel, and the mutation ID field is the operator identifier of the WiFi channel, which can be used to determine the proxy server cluster. .
  • the client APP 713 may also receive multiple downlink data packets sent in parallel by the load balancing server 731 from the WiFi channel and the load balancing server 732 from the 4G channel through the downlink processing module 7133, and send the downlink data through the downlink processing module 7133. After the downlink header in the packet is removed, it is deduplicated by the deduplication logic, and is sequentially sent to the game client 711 through the virtual network card 7131 and the real network card 712.
  • the downlink header may include the following information:
  • the load balancing server 731 in FIG. 7 may further include a proxy service mapping module 7311, an uplink thread 7312, and a downlink thread 7313; the load balancing server 732 may further include a proxy service mapping module 7321, an uplink thread 7322, and a downlink thread 7323.
  • the proxy server 740 may further include a thread maintenance module 741, a communication maintenance module 742, a client 1 thread, a client 2 thread, and up to a client n thread, where it is assumed that the client n thread 743 may further include a downlink processing module 7431 and an uplink processing module 7432.
  • a proxy service mapping module 7311 an uplink thread 7312, and a downlink thread 7313
  • the load balancing server 732 may further include a proxy service mapping module 7321, an uplink thread 7322, and a downlink thread 7323.
  • the proxy server 740 may further include a thread maintenance module 741, a communication
  • the WiFi channel and the 4G channel are provided by different operators as an example. Therefore, two load balancing servers 731 and 732 are required. Similarly, if the The method is applied to three or more channels, the multi-channel is provided by several operators, and corresponding load balancing servers are required accordingly. Similarly, if the multiple channels are provided by the same operator, only one load balancing server may be required.
  • proxy server cluster In addition, although only one proxy server is shown in FIG. 7, in practice, it may be a proxy server cluster.
  • the load balancing server needs to determine the same proxy server (also referred to as a proxy service node) in the proxy server cluster according to the information in the uplink header of the uplink data packet.
  • the proxy server cluster corresponding to the main channel can be determined according to the main channel identifier in the uplink header. For determining a target cluster of the same proxy server.
  • the multi-channel data transmission method provided in the embodiment of the present application sends the same game data packet through two channels of WiFi and 4G at the same time.
  • the game data packet of one of the network channels can reach normally, the user experience can still remain normal, that is, the The client-server data transmission and reception network channel performs disaster recovery processing, which can effectively prevent problems such as packet loss and high latency caused by WiFi or 4G network jitter.
  • the proxy server can also shield the game client and game server from network changes.
  • the game client and game server are not aware of the switching behavior of different network environments, and can smoothly switch.
  • the method provided by the embodiments of the present application can effectively improve the real-time game stutter experience in a complex mobile network environment, and can still ensure data transmission well in the case of poor wireless WiFi or 4G networks. Effectiveness, especially for common WiFi wireless interference, the optimization rate can be as high as 90%.
  • FIG. 8 schematically illustrates a schematic diagram of a client APP sending uplink data packets in multiple channels according to an embodiment of the present application.
  • the virtual network card 7131 in the client APP 713 sends the game data packet to the uplink processing module 7132.
  • the uplink processing module 7132 encapsulates the game data packet with an uplink header, and generates two uplink data packets, which are respectively passed The WiFi channel and the 4G channel send these two uplink data packets.
  • FIG. 9 schematically illustrates a schematic diagram of a client APP receiving downlink data packets in multiple channels according to an embodiment of the present application.
  • the downlink processing module 7133 in the client APP 713 performs deduplication processing on the downlink data packet according to the downlink packet header, and further sends the game data packet after the deduplication processing to remove the downlink header from the downlink data packet to
  • the virtual network card 7131 is forwarded to the real network card 712.
  • FIG. 10 schematically illustrates a flowchart of a data packet deduplication method according to an embodiment of the present application. It should be noted that the two data packet deduplication methods provided in Figure 10-12 can be applied to both the client and the proxy server.
  • the data packet deduplication method provided in the embodiment of the present application may include the following steps.
  • step S1001 a new packet is received.
  • a new downlink data packet is received; for the proxy server, a new uplink data packet is received.
  • step S1002 it is determined whether the packet sequence number curSeqno of the new packet is greater than the maximum packet receiving sequence number of its channel; if the packet sequence number curSeqno of the new packet is greater than the maximum packet receiving sequence number of its channel, then proceed to step S1003; if the packet of the new package is If the serial number curSeqno is less than or equal to the maximum packet serial number of the channel, the process jumps to step S1006.
  • the channel type of the new packet can be determined based on the channel identifier in its header (upstream header or downstream header). For example, if the channel identifier of the new packet is 0, you can It is known that the new packet is sent through the WiFi channel. At this time, the maximum packet receiving sequence number of the new channel corresponding to the new packet can be obtained. If the packet sequence number curSeqno of the new packet is greater than the maximum packet receiving sequence number of the WiFi channel, it means that for the WiFi channel This is a newly received packet. If the packet serial number curSeqno of the new packet is less than or equal to the maximum packet serial number of the WiFi channel, it means that for the WiFi channel, this is a previously received packet.
  • the maximum packet receiving sequence number of the channel refers to the maximum packet sequence number received before the corresponding channel, but for the multi-channel, the maximum packet receiving sequence number of this channel may not be equal to the following The maximum packet receiving sequence number of the client.
  • step S1003 the maximum packet receiving sequence number of the channel is updated.
  • the maximum packet sequence number of the WiFi channel is updated to 2.
  • the new packet is a new packet that has never been received before with respect to the WiFi channel
  • the channel information of the new packet such as the channel address
  • the channel information of the new packet is consistent with the previously stored channel address of the WiFi channel. If the two are inconsistent, update the channel address of the WiFi channel to ensure that the latest channel address is stored, so that the correct connection between the client and the proxy server can be maintained.
  • step S1005 the channel information of its channel is updated.
  • step S1006 it is determined whether the packet sequence number curSeqno of the new packet is greater than the maximum packet receiving sequence number MaxSeqno of the client; if the packet sequence number curSeqno of the new packet is larger than the maximum packet receiving sequence number MaxSeqno of the client, proceed to step S1007.
  • the maximum packet receiving sequence number MaxSeqno of the client refers to the maximum packet sequence number received and transmitted before being received by the WiFi channel and the 4G channel.
  • the new packet is a new packet that has never been received before, and the new packet is reserved at this time.
  • step S1007 the skipped packet sequence number between the packet sequence number curSeqno of the new packet and the client's maximum packet sequence number MaxSeqno is put into the unreceived packet set.
  • the packets sent in order according to time sequence may not have the same arrival time. For example, a packet with a large packet sequence number is sent later but may arrive first. At this time, the packet sequence number of the new packet may be higher than that of the customer.
  • the first threshold may be set to 10.
  • this application is not limited to this.
  • step S1009 the minimum number of unreceived packets is deleted from the unreceived packet set.
  • the purpose of this step is to limit the size of the unreceived packet set and keep the number of packet sequence numbers in the unreceived packet set within the first threshold range.
  • step S1010 the maximum packet receiving sequence number MaxSeqno of the client is updated.
  • step S1011 this packet is reserved for forwarding.
  • steps S1009, S1010, and S1011 may not be executed in sequence, and may be executed in parallel.
  • the new packet is discarded.
  • the packet number of the new packet is 7
  • this first threshold can be adjusted. The purpose is to limit the length of time a proxy server or client waits for a certain packet. At this time, a certain amount of packet loss can be tolerated. If the response level is high, the first threshold may be set smaller, for example, 10; if the response level is low, the first threshold may be set larger, for example, 100. Furthermore, it is also possible to set the first threshold to the maximum value of all packet sequence numbers, which is equivalent to waiting indefinitely without packet loss.
  • step S1013 it is determined whether the packet sequence number curSeqno of the new packet is in the unreceived packet set; if the packet sequence number curSeqno of the new packet is in the unreceived packet set, proceed to step S1014; if the new packet is If the packet sequence number curSeqno is not in the unreceived packet set, go to step S1015.
  • step S1014 the packet sequence number curSeqno of the new packet is deleted from the unreceived packet set, and the process jumps to step S1011, where the new packet is retained and forwarded.
  • step S1015 the new packet is dropped.
  • the method may further include: updating the number of first arriving packets of each channel, and the number of arriving packets of each channel, so that it can be used to count the data transmission effect of each channel.
  • FIG. 11 schematically illustrates an example of a method for deduplication based on the data packet shown in FIG. 10.
  • sequence numbers of the packets sent by the client in the WiFi channel is 1, 2, 3, and 4
  • sequence numbers of the packets sent by the client in the 4G channel are 1, 2, 3, and 4, respectively.
  • the sequence numbers of the packets in the receiving sequence are, in order, 1, 4G channel of the WiFi channel, 1, 4 of the WiFi channel, 2 of the 4G channel, 2 and 3 of the WiFi channel, and 3 and 4 of the 4G channel.
  • the proxy server receives a packet with a packet number of 1 on the 4G channel.
  • the proxy server receives a packet with a packet sequence number 4 of the WiFi channel.
  • the proxy server receives a packet with a packet number of 2 on the 4G channel.
  • MaxSeqno 4, MaxSeqno> curSeqno & MaxSeqno-curSeqno ⁇ 10, find the packet sequence number 2 in the unreceived packet set, retain this packet, and remove it from the unreceived packet set Delete, only the packet number 3 is left in the set of unreceived packets.
  • the packet sequence number of the forwarding sequence of the proxy server is, in order, WiFi channel 1, WiFi channel 4, 4G channel 2, and WiFi channel 3.
  • FIG. 12 schematically illustrates a flowchart of a data packet deduplication method according to another embodiment of the present application.
  • step S1201 a new packet is received.
  • step S1202 it is determined whether the serial number queue is empty; if the serial number queue is empty, go to step S1208; if the serial number queue is not empty, go to step S1203.
  • the serial number queue corresponding to the client is empty, the serial number queue and the time stamp of the new packet are added to the serial number queue, and the packet is retained and forwarded.
  • step S1203 the sequence number queue is traversed forward.
  • the sequence number queue is traversed forward to determine the sequence number of the packet in which the time difference between the addition time and the current time exceeds the second threshold (for example, 500 ms), and the sequence number And its timestamp are removed from the sequence queue.
  • the second threshold for example, 500 ms
  • the second threshold value is also an adjustable value.
  • the time limit for maintaining the sequence number queue is maintained to avoid too many packet sequence numbers in the queue. This method may result in, for example, the sequence number of the packet received before 500ms. Because the sequence number is removed from the sequence number queue, the same packet sequence number is re-collected after 500ms, that is, the packet may be received repeatedly, but the packet will not be lost.
  • step S1205 the sequence queue is traversed backward.
  • forward traversal and reverse traversal in the above steps are only for saving execution time, and are not limited in practice.
  • step S1206 it is determined whether the packet sequence number of the new packet is in the sequence number queue; if the packet sequence number of the new packet is in the sequence number queue, the process proceeds to step S1207.
  • step S1207 the new packet is dropped.
  • step S1208 a packet sequence number of the new packet and a time stamp at this time are added to the sequence number queue.
  • step S1209 the new packet is reserved for forwarding.
  • the deduplication logic is not limited to the two methods exemplified above, and any appropriate deduplication method may be used to deduplicate the packet according to the actual situation.
  • FIG. 13 schematically illustrates a schematic diagram of a load balancing server according to an embodiment of the present application.
  • WiFi and 4G are inter-networked (between different operators).
  • WiFi broadband operator is mobile and the 4G operator is telecommunications.
  • load balancing services need to be provided at the dual-channel background access layer.
  • FIG. 13 it is a load balancing server logic in a dual-channel server.
  • a load balancing server 731 is taken as an example for illustration.
  • the client APP sends the uplink data packet of the WiFi channel or the 4G channel to the corresponding operator access point.
  • the load balancing server 731 receives the uplink data packet through the WiFi channel. At this time, the uplink data packet includes the uplink channel header and the game data packet. The load balancing server 731 parses the uplink channel header and obtains the clientkey value and the mutationID field corresponding to the header. The operator ID of the main channel, so that you can know which operator's proxy server in the proxy server cluster to send the received uplink data packets to. Specifically, the proxy service mapping module 7311 in the load balancing server 731 can calculate the proxy service node according to the clientkey value.
  • the uplink thread 7312 in the load balancing server 731 further encapsulates the received uplink data packet with an uplink internal communication packet header to form a packet including the upstream internal communication packet header, the upstream channel packet header, and the game data packet. And forward it to the calculated proxy server 740.
  • the uplink internal communication packet header may store client address information.
  • client address information E.g:
  • FIG. 14 schematically illustrates a logic sequence diagram of internal interaction between a load balancing server and a proxy server according to an embodiment of the present application.
  • step S1 The client sends uplink data packets to the load balancing server through each channel, and specifically sends the uplink thread monitoring port 19000 to the load balancing server (for example, it is not limited to this).
  • Step S2 The proxy service mapping module in the load balancing server communicates with redis bidirectionally to obtain the latest proxy service node information. At the same time, the proxy service mapping module calculates the currently received clientkey based on the clientkey in the upstream channel header of the received uplink data packet. The uplink data packet should be sent to the client-specific proxy service node.
  • redis can be regarded as a database. Since the proxy server in the proxy server cluster may change, such as adding a new proxy server, deleting the old proxy server, or replacing the original proxy server, in order for the proxy service mapping module to calculate an accurate dedicated proxy service node, you need to These latest proxy server information is stored in redis, and then the proxy service mapping module of the load balancing server reads the latest proxy server information in redis for calculation when calculating the proxy service node to which the current packet is to be forwarded.
  • the storage device for storing proxy server information is not limited to redis, and may be any other type of storage device.
  • Step S3 Based on the received uplink data packet, the load balancing server continues to encapsulate the upstream internal communication packet header and forwards it to the dedicated proxy service node found in step S2.
  • Step S4 Create a client-specific thread through the main thread of the proxy server, remove the uplink internal communication header and uplink channel header of the uplink data packet through the client-specific thread, and delete the game in the deduplicated uplink data packet.
  • the data packet is sent to the game server.
  • the proxy server starts a dedicated thread for each client, and is used to monitor whether each client and the game server have sent a new packet.
  • Step S5 The proxy server receives a reply data packet returned by the game server in response to the game data packet received by the proxy server through the client-specific thread.
  • Step S6 The proxy server encapsulates the reply data packet with a downlink internal communication header and a downlink channel header to form a downlink data packet, and sends the downlink data packet to each channel to the load balancing server.
  • Step S7 The load balancing server sends downlink data packets to each channel to the client through port 19001.
  • FIG. 15 schematically illustrates a proxy service mapping module of a load balancing server according to an embodiment of the present application.
  • the proxy service mapping module divides the proxy server into several clusters according to an operator, for example, four clusters of telecommunications, mobile, China Unicom, and small and medium-sized broadband operators.
  • the proxy service mapping module evenly distributes N (N is an integer greater than or equal to 0) proxy service nodes of each cluster in a range of 0 to 4294967295 (this value is for illustration only, and the application is not limited to this). .
  • the corresponding proxy service node is calculated based on the clientkey value, and the calculation formula may be as follows:
  • svrNum (number of dual-channel proxy nodes) // here is assumed to be 4
  • svrInterval MAX / svrNum /// This is assumed to be 1073741823.75;
  • index (clientkey / svrInterval)% svrNum; //% is the remainder operation
  • index is the calculated proxy node number, and each node number represents the address of a proxy server.
  • each client has a dedicated thread, that is, after the same transmission channel is established, the clientkey values of multiple uplink data packets sent by the WiFi channel and the 4G channel are the same. If the transmission channel is disconnected this time, after the same client re-establishes the transmission channel, the clientkey value will change.
  • the proxy service mapping module accesses the redis cluster at predetermined intervals, for example, every second, to obtain the latest list of proxy servers. . If it is inconsistent with the latest proxy server node, complete the operations of adding, deleting or replacing.
  • FIG. 16 schematically illustrates a schematic diagram of a proxy service mapping module of a load balancing server according to another embodiment of the present application.
  • node update logic As shown in FIG. 16, an example of node update logic is illustrated. Assume that node 4 is added after node 3. According to the above formula for calculating index, because svrInterval is equally spaced, you need to add a virtual node after each original node, such as adding virtual nodes 0, 1, 2 to Keep the consistency of the above node calculation formula. Among them, the virtual node and the address information of the proxy server represented by the previous node are the same. At this time, the number of nodes svrNum is doubled, for example, svrNum is equal to 8.
  • the added node can be added at any position, and is not limited to being added after node 3.
  • FIG. 17 schematically illustrates a proxy service mapping module of a load balancing server according to another embodiment of the present application.
  • an instance of the proxy service node is deleted. Assuming that node 3 is deleted, a virtual node 2 needs to be added to make up the deleted position. The same reason is to maintain the equal interval feature.
  • the virtual node address information is the same as the previous node.
  • FIG. 18 schematically illustrates a proxy service mapping module of a load balancing server according to still another embodiment of the present application.
  • FIG. 18 it is an example of replacing a proxy service node. Assuming that the old node 3 is replaced, the information of replacing the node 3 with the new node 4 is sufficient. For example, the performance of a proxy server is degraded and replaced with a new proxy server.
  • FIG. 19 schematically illustrates a logic sequence diagram of a proxy server according to an embodiment of the present application.
  • step S1 the proxy server receives an uplink data packet.
  • Step S2 The proxy server removes the uplink channel header and the uplink internal communication header of the uplink data packet and deletes the header, and then sends the game data packet to the game server.
  • the proxy server updates the thread maintenance module, for which the client creates a dedicated thread at the proxy server to serve, and updates the information in the thread maintenance module.
  • the proxy server when the proxy server newly receives an uplink data packet sent by a client, it removes the uplink channel header and uplink internal communication header of the uplink data packet, obtains the client address information, and records the client address information in the communication. Maintenance module, so that when the subsequent thread maintenance module encapsulates the downstream packet header, it can copy a corresponding client address information from the communication maintenance module and encapsulate it into the downstream internal communication header, so that the proxy server can know the downstream data packet. Which client to forward to.
  • the client sends the channel information of the uplink data packet to the proxy server in real time to facilitate the channel switching of the proxy server, thereby ensuring that the proxy server can update the client at the first time when the 4G or WiFi channel is abnormally switched.
  • Channel information corresponding to the client The ver and type fields of the channel header maintained by this channel information.
  • the above channel switching mainly refers to 4G internal switching or WiFi internal switching, because the 4G address and the WiFi address can be changed. Therefore, the embodiment of the present application can maintain the relationship between the client and the proxy server according to the latest channel information. Connection.
  • WiFi is abnormal and cannot be connected to the network. If WiFi is abnormal and cannot be connected to the network, you can switch 4G to the main channel and change the ver field of the channel header accordingly. At this time, you can send downlink data packets only through the 4G channel. To the client, but at this time, the proxy server in the proxy server cluster of the corresponding operator of the WiFi can still be used to complete the encapsulation of the downlink packet header and other operations, and it is not necessary to switch to the proxy server cluster of the 4G operator.
  • the proxy server may identify the client data sent from the 4G and WiFi channels according to the unique identifier clientkey value of the client in the uplink channel header in the uplink data packet, and perform deduplication processing.
  • the deduplication algorithm can refer to The above-mentioned embodiments of Figs. 10-12.
  • Step S3 The game server returns a response data packet in response to the game data packet.
  • Step S4 The proxy server obtains the client address from the communication maintenance module and encapsulates it into the downlink internal communication header of the reply data packet, and encapsulates the reply data packet with a downlink channel header and then forwards it.
  • the client thread created by the proxy server listens to its proprietary link established with the game server, and after receiving the response data packet returned by the game server, according to its latest WiFi channel and 4G in the communication maintenance module Address information of the channel. After encapsulating the downstream channel header and the downstream internal communication header, the two downstream data packets that are formed are sent to the two channels respectively.
  • the proxy server may also periodically clean up the client channel information. If no client data passes through the proxy server within the timeout period, the client thread and channel information data are cleared.
  • FIG. 20 schematically illustrates a schematic diagram of a proxy server sending downlink data packets in multiple channels according to an embodiment of the present application.
  • the proxy server 740 sends the downlink data packet, which is the reply data packet encapsulated with the downlink internal communication header and the downlink channel header, to the load balancing server 731 and the load balancing server 732 through the WiFi channel and the 4G channel, respectively.
  • the load balancing server 731 After the load balancing server 731 removes the downlink internal communication header of the downlink data packet, it sends it to the service client (not shown in the figure) through the WiFi channel.
  • the load balancing server 732 After the load balancing server 732 removes the downlink internal communication header of the downlink data packet, it sends it to a service client (not shown in the figure) through a 4G channel.
  • the downlink thread in the load balancing server after the downlink thread in the load balancing server receives the downlink data packet sent by the proxy server, it removes the downlink internal communication packet header and obtains the client address information. The data packet is forwarded to the business client.
  • the main role of the dual-channel load balancing server in this solution is to send data packets of different operators from the wifi channel and the 4g channel to the same dual-channel proxy server through the proxy service mapping module.
  • a dual-channel proxy server cluster but in this solution you only need to use the operator ’s dual-channel proxy server cluster corresponding to the main channel (the default is the wifi channel), even if the wifi channel may be abnormally closed in the future, pass ver and type
  • the field changes the main channel to the 4g channel.
  • the downlink data packet is still sent through the operator's dual-channel proxy server cluster corresponding to the wifi channel.
  • downlink packets can be sent only through the main channel, but in this solution downlink packets are sent through two channels.
  • the method provided in the embodiment of the present application is relatively flexible, and most services can be accessed at zero cost without any change and adaptation of the services.
  • the user is completely unaware, and can prevent more than 70% of client stalls, especially when the WiFi network is more complicated, the effect is significant.
  • FIG. 21 schematically illustrates a block diagram of a multi-channel data transmission device according to an embodiment of the present application.
  • the multi-channel data transmission device 2100 may include an uplink data receiving module 2110, an uplink data parsing module 2120, an uplink data deduplication module 2130, and an uplink data forwarding module 2140.
  • the uplink data receiving module 2110 is configured to receive multiple uplink data packets in parallel through multiple channels.
  • An uplink data analysis module 2120 is configured to parse the multiple uplink data packets to obtain multiple target service data packets and multiple uplink headers.
  • the uplink data deduplication module 2130 is configured to perform deduplication processing on the multiple target service data packets according to the multiple uplink headers.
  • the uplink data forwarding module 2140 is configured to send the target service data packet retained after deduplication to the target service server.
  • Each uplink packet header may include a packet sequence number of each uplink data packet.
  • curSeqno is the packet sequence number of the uplink data packet
  • MaxSeqno is the maximum packet receiving sequence number of the client
  • recvThred is the first threshold.
  • the uplink data deduplication module 2130 may include a second packet retention unit configured to set the packet sequence number of the uplink data packet if the packet sequence number of the uplink data packet is different from the packet sequence number in the sequence queue. Adding to the sequence number queue and retaining the corresponding target service data packet; a second packet loss unit for discarding the corresponding target service data packet if the packet sequence number of the uplink data packet is the same as any of the packet sequence numbers in the sequence queue .
  • each uplink packet header further includes a channel identifier and channel information of each uplink data packet.
  • the multi-channel data transmission device 2100 may further include: a channel type judgment module for judging the channel type of the uplink data packet according to the channel identifier; and a channel information update module for the packet sequence number of the uplink data packet greater than The maximum packet receiving sequence number of the channel of the corresponding channel type, and the corresponding channel information is not consistent with the channel information stored in the corresponding channel type, then the channel information of the corresponding channel type is updated.
  • the multi-channel data transmission device 2100 may further include: a reply data receiving module, configured to receive a reply data packet generated by the target service server in response to the target service data packet; a downlink data generation module, According to the latest channel information of each channel type, the response data packet is respectively encapsulated with corresponding downlink headers to generate multiple downlink data packets; a downlink data sending module is configured to send the multiple downlink data packets in parallel through the multi-channel To the business client.
  • a reply data receiving module configured to receive a reply data packet generated by the target service server in response to the target service data packet
  • a downlink data generation module According to the latest channel information of each channel type, the response data packet is respectively encapsulated with corresponding downlink headers to generate multiple downlink data packets
  • a downlink data sending module is configured to send the multiple downlink data packets in parallel through the multi-channel To the business client.
  • FIG. 22 schematically illustrates a block diagram of a multi-channel data transmission device according to another embodiment of the present application.
  • the multi-channel data transmission device 2200 may include: a target data acquisition module 2210, an uplink header encapsulation module 2220, and an uplink data sending module 2230.
  • the target data acquisition module 2210 is configured to acquire a target service data packet.
  • the uplink header encapsulation module 2220 is configured to encapsulate the target service data packet with an uplink header, respectively, to form multiple uplink data packets.
  • the uplink data sending module 2230 is configured to send the multiple uplink data packets to the proxy server in parallel through multiple channels.
  • Each uplink packet header may include a packet sequence number of each uplink data packet.
  • the multi-channel data transmission device 2200 may further include: a downlink data receiving module configured to receive multiple downlink data packets generated in response to the target service data packet in parallel through the multi-channel; downlink data analysis A module for parsing the multiple downlink data packets to obtain multiple reply data packets and multiple downlink headers; a downlink data deduplication module for deduplicating the multiple reply data packets according to the multiple downlink headers deal with.
  • a downlink data receiving module configured to receive multiple downlink data packets generated in response to the target service data packet in parallel through the multi-channel
  • downlink data analysis A module for parsing the multiple downlink data packets to obtain multiple reply data packets and multiple downlink headers
  • a downlink data deduplication module for deduplicating the multiple reply data packets according to the multiple downlink headers deal with.
  • the target data acquisition module 2210 includes: a service server information acquisition unit, configured to control the server according to a service configuration request, to acquire target service server information; and a filtering policy setting unit, configured to according to the target service server information Setting a filtering policy; a target service data interception unit, configured to intercept the target service data packet according to the filtering policy.
  • the technical solution according to the embodiment of the present application may be embodied in the form of a software product, and the software product may be stored in a non-volatile storage medium (which may be a CD-ROM, a U disk, a mobile hard disk, etc.) or a network.
  • a non-volatile storage medium which may be a CD-ROM, a U disk, a mobile hard disk, etc.
  • There are several instructions included to enable a computing device (which may be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiment of the present application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

本申请的实施例提供了一种多通道数据传输方法及装置、计算机可读介质和电子设备。所述多通道数据传输方法包括:通过多通道并行接收多个上行数据包;解析所述多个上行数据包获得多个目标业务数据包和多个上行包头;根据所述多个上行包头对所述多个目标业务数据包进行去重处理;将去重处理后保留的目标业务数据包发送给目标业务服务器;其中,各上行包头包括各上行数据包的包序号。本申请实施例的技术方案能够通过多通道并行传输上行数据包,并通过去重处理,实现目标业务数据包的可靠有效传输。

Description

多通道数据传输方法及装置
本申请要求于2018年08月15日提交中国专利局、申请号为2018109310957、申请名称为“多通道数据传输方法及装置”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域,具体涉及数据传输技术。
背景技术
目前,数据传输一般通过WiFi(Wireless Fidelity,无线保真)通道或者蜂窝网络实现,其中所述蜂窝网络可以包括GSM(Global System for Mobile Communication,全球移动通信系统)网络、CDMA(Code Division Multiple Access,码分多址)网络、FDMA(frequency division multiple access,频分多址)网络、TDMA(time division multiple access,时分多址)网络、3G/4G/5G通道。其中,3GPP(3rd Generation Partnership Project,第三代合作伙伴计划)的目标是实现由2G网络到3G/4G/5G网络的平滑过渡,保证未来技术的后向兼容性,支持轻松建网及系统间的漫游和兼容性。其中,在WiFi通道下传输数据具有延迟低的优点,但WiFi通道不稳定,容易出现信道干扰、同频干扰、信号强度变差等现象,从而导致终端到WiFi热点间的延迟变高或者丢包。而蜂窝网络(例如4G)虽然相对稳定,但延迟会高于WiFi。
即相关技术中,不论终端选择何种网络传输数据,都有可能影响到用户体验,尤其是在传输游戏数据时,这种影响更加明显。这是因为,实时手游等类似应用,都面临客户端和服务端的频繁通信,且以高频小包为主,这类应用对网络环境的要求很高,低延迟、高稳定的特性成为这类应用的强需求。与此同时,WiFi本身的CSMA/CA(Carrier Sense multiple Access/Collision Avoidance,即载波监听多路访问/冲突避免)机制原理,就会存在信道竞争,无线WiFi信道重叠或同频又会相互干扰,信号差等都会导致业务丢包或延迟加剧。
相关技术中,为了改善游戏数据传输效果,有支持WiFi和4G通道优选的单通道发包方案,即在WiFi信号变差的情况下,使用4G通道发包。然而,这种单通道发包方案至少存在如下缺点:
第一,在WiFi网络已经变差的情况下,才开启转换4G通道传输的操作,属于事后补救措施,此时用户体验已经受损。
第二,用户较难适应因网络环境的切换等操作引起的游戏客户端切网,如此可能为用户带来较严重的卡顿体验。
第三,在网络抖动时,只能将数据从网络较恶劣的一路切换至较好的一 路,例如在WiFi变差时用4G通道发送部分数据包,而无法在WiFi或4G网络抖动时,规避数据包丢失和高延迟情况。
综上,可见目前需要一种新的数据传输方法,以保障数据的稳定传输。
需要说明的是,在上述背景技术部分公开的信息仅用于加强对本申请申请的背景的理解,因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。
发明内容
本申请实施例的目的在于提供一种多通道数据传输方法及装置、计算机可读介质和电子设备,以克服相关技术在数据传输过程中存在的网络卡顿、丢包、高延迟等问题。
本申请的其他特性和优点将通过下面的详细描述变得显然,或部分地通过本申请的实践而习得。
根据本公开的一个方面,提供一种多通道数据传输方法,应用于代理服务器,包括:通过多通道并行接收多个上行数据包;解析所述多个上行数据包获得多个目标业务数据包和多个上行包头;根据所述多个上行包头对所述多个目标业务数据包进行去重处理;将去重处理后保留的目标业务数据包发送给目标业务服务器;其中,各上行包头包括各上行数据包的包序号。
在本公开的一种示例性实施例中,所述根据所述多个上行包头对所述多个目标业务数据包进行去重处理,包括:若(MaxSeqno-curSeqno)>recvThred,则丢弃相应目标业务数据包;若(MaxSeqno-curSeqno)<=recvThred,且curSeqno不在未收包集合中,则丢弃相应目标业务数据包;若curSeqno>MaxSeqno,则保留相应业务数据包;若(MaxSeqno-curSeqno)<=recvThred,且curSeqno在所述未收包集合中,则保留相应目标业务数据包;其中,curSeqno为上行数据包的包序号,MaxSeqno为客户端最大收包序号,recvThred为第一阈值。
在本公开的一种示例性实施例中,所述根据所述多个上行包头对所述多个目标业务数据包进行去重处理,包括:若上行数据包的包序号与序号队列中的包序号均不相同,则将上行数据包的包序号加入至所述序号队列,并保留相应目标业务数据包;若上行数据包的包序号与所述序号队列中的任意一个包序号相同,则丢弃相应目标业务数据包。
在本公开的一种示例性实施例中,各上行包头还包括各上行数据包的通道标识和通道信息;所述方法还包括:根据通道标识判断上行数据包的通道类型;若上行数据包的包序号大于相应通道类型的通道最大收包序号,且相应通道信息与相应通道类型存储的通道信息不一致,则更新相应通道类型的通道信息。
在本公开的一种示例性实施例中,还包括:接收所述目标业务服务器响应于所述目标业务数据包生成的回复数据包;根据各通道类型最新的通道信 息给所述回复数据包分别封装相应下行包头,生成多个下行数据包;将所述多个下行数据包通过所述多通道并行发送至业务客户端。
根据本公开的一个方面,提供一种多通道数据传输方法,应用于业务客户端,包括:获取目标业务数据包;给所述目标业务数据包分别封装上行包头,形成多个上行数据包;通过多通道并行发送所述多个上行数据包至代理服务器;其中,各上行包头包括各上行数据包的包序号。
在本公开的一种示例性实施例中,还包括:通过所述多通道并行接收响应于所述目标业务数据包生成的多个下行数据包;解析所述多个下行数据包获得多个回复数据包和多个下行包头;根据所述多个下行包头对所述多个回复数据包进行去重处理。
在本公开的一种示例性实施例中,所述获取目标业务数据包,包括:根据业务配置请求控制服务器,获取目标业务服务器信息;根据所述目标业务服务器信息设定过滤策略;根据所述过滤策略截获所述目标业务数据包。
根据本公开的一个方面,提供一种多通道数据传输装置,包括:上行数据接收模块,配置为通过多通道并行接收多个上行数据包;上行数据解析模块,配置为解析所述多个上行数据包获得多个目标业务数据包和多个上行包头;上行数据去重模块,配置为根据所述多个上行包头对所述多个目标业务数据包进行去重处理;上行数据转发模块,配置为将去重后保留的目标业务数据包发送给目标业务服务器;其中,各上行包头包括各上行数据包的包序号。
根据本公开的一个方面,提供一种多通道数据传输装置,包括:目标数据获取模块,配置为获取目标业务数据包;上行包头封装模块,配置为给所述目标业务数据包分别封装上行包头,形成多个上行数据包;上行数据发送模块,配置为通过多通道并行发送所述多个上行数据包至代理服务器;其中,各上行包头包括各上行数据包的包序号。
根据本公开的一个方面,提供一种多通道数据传输系统,包括:业务客户端,配置为获取目标业务数据包,给所述目标业务数据包分别封装上行包头,形成多个上行数据包并发送;代理服务器,配置为通过多通道并行接收所述多个上行数据包,解析所述多个上行数据包获得多个目标业务数据包和多个上行包头,根据所述多个上行包头对所述多个目标业务数据包进行去重处理,将去重处理后保留的目标业务数据包发送给目标业务服务器。
在本公开的一种示例性实施例中,其中:所述代理服务器还配置为接收所述目标业务服务器响应于所述目标业务数据包生成的回复数据包,根据各通道类型最新的通道信息给所述回复数据包分别封装相应下行包头,生成多个下行数据包并发送;所述业务客户端还配置为通过所述多通道并行接收所述多个下行数据包,解析所述多个下行数据包获得多个回复数据包和多个下行包头,根据所述多个下行包头对所述多个回复数据包进行去重处理。
在本公开的一种示例性实施例中,还包括:负载均衡服务器,配置为通过所述多通道并行接收所述多个上行数据包,并根据上行包头确定所述多个上行数据包的代理服务器,将所述多个上行数据包通过所述多通道并行发送至所述代理服务器。
根据本公开的一个方面,提供一种计算机可读介质,其上存储有计算机程序,所述程序被处理器执行时实现如上述任一实施例所述的方法。
根据本公开的一个方面,提供一种电子设备,包括:一个或多个处理器;存储装置,配置为存储一个或多个计算机程序,当所述一个或多个计算机程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现如上述任一实施例所述的方法。
在本申请的一些实施例所提供的技术方案中,通过多通道并行接收多个上行数据包;并通过解析这多个上行数据包,获得多个目标业务数据包和多个上行包头;然后,根据多个上行包头对多个目标业务数据包进行去重处理;之后,将去重处理后保留的目标业务数据包发送给目标业务服务器;其中,各上行包头包括各上行数据包的包序号。一方面,通过多通道同时收包,可以保障目标业务数据包的传输稳定性和有效性;另一方面,通过对并行接收的上行数据包聚合去重后再转发给目标业务服务器,对目标业务服务器屏蔽了网络变化,保证目标业务服务器对不同网络环境的变化无感知,不对目标业务服务器的运行造成影响。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。在附图中:
图1示出了可以应用本申请实施例的多通道数据传输方法或多通道数据传输装置的示例性系统架构的示意图;
图2示出了适用于本申请实施例的电子设备的计算机系统的结构示意图;
图3示意性示出了根据本申请的一实施例的多通道数据传输方法的流程图;
图4示意性示出了根据本申请的另一实施例的多通道数据传输方法的流程图;
图5示意性示出了根据本申请的一实施例的多通道数据传输系统的示意图;
图6示意性示出了根据本申请的另一实施例的多通道数据传输系统的示意图;
图7示意性示出了根据本申请的一实施例的多通道数据传输方法的整体架构图;
图8示意性示出了根据本申请的一实施例的客户端APP多通道发送上行数据包的示意图;
图9示意性示出了根据本申请的一实施例的客户端APP多通道接收下行数据包的示意图;
图10示意性示出了根据本申请的一实施例的数据包去重方法的流程图;
图11示意性示出了基于图10所示数据包去重方法的一个实例的示意图;
图12示意性示出了根据本申请的另一实施例的数据包去重方法的流程图;
图13示意性示出了根据本申请的一实施例的负载均衡服务器的示意图;
图14示意性示出了根据本申请的一实施例的负载均衡服务器与代理服务器内部交互逻辑时序图;
图15示意性示出了根据本申请的一实施例的负载均衡服务器的代理服务映射模块的示意图;
图16示意性示出了根据本申请的另一实施例的负载均衡服务器的代理服务映射模块的示意图;
图17示意性示出了根据本申请的又一实施例的负载均衡服务器的代理服务映射模块的示意图;
图18示意性示出了根据本申请的再一实施例的负载均衡服务器的代理服务映射模块的示意图;
图19示意性示出了根据本申请的一实施例的代理服务器的逻辑时序图;
图20示意性示出了根据本申请的一实施例的代理服务器多通道发送下行数据包的示意图;
图21示意性示出了根据本申请的一实施例的多通道数据传输装置的框图;
图22示意性示出了根据本申请的另一实施例的多通道数据传输装置的框图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的范例;相反,提供这些实 施方式使得本申请将更加全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。
此外,所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中,提供许多具体细节从而给出对本申请的实施例的充分理解。然而,本领域技术人员将意识到,可以实践本申请的技术方案而没有特定细节中的一个或更多,或者可以采用其它的方法、组元、装置、步骤等。在其它情况下,不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。
附图中所示的方框图仅仅是功能实体,不一定必须与物理上独立的实体相对应。即,可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
附图中所示的流程图仅是示例性说明,不是必须包括所有的内容和操作/步骤,也不是必须按所描述的顺序执行。例如,有的操作/步骤还可以分解,而有的操作/步骤可以合并或部分合并,因此实际执行的顺序有可能根据实际情况改变。
图1示出了可以应用本申请实施例的多通道数据传输方法或多通道数据传输装置的示例性系统架构100的示意图。
如图1所示,系统架构100可以包括终端设备101、102、103中的任意一种或多种,网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。
应理解,图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备、网络和服务器。比如服务器105可以是多个服务器组成的服务器集群等。
用户可以使用终端设备101、102、103通过网络104与服务器105交互,以接收或发送消息等。终端设备101、102、103可以是具有数据传输功能的各种电子设备,包括但不限于智能手机、平板电脑、便携式计算机和台式计算机、智能聊天机器人等等。
服务器105可以是提供相关服务的服务器。例如,用户利用终端设备103(也可以是终端设备101或102)向服务器105发送获取游戏相关信息和/或资源的请求;服务器105可以基于其接收的游戏相关信息和/或资源的信息请求,相应地获取游戏相关信息和/或资源,并将游戏相关信息和/或资源反馈给终端设备103,进而终端设备103可以显示其接收的游戏相关信息和/或资源。用户根据终端设备103上显示的游戏相关信息和/或资源,利用终端设备103(也可以是终端设备101或102)向服务器105发送游戏操作 指令;服务器105可以基于其接收的游戏操作指令,相应地向终端设备103返回该游戏操作指令的执行结果,终端设备103相应地显示其接收到的游戏操作指令的执行结果。
图2示出了适于用来实现本申请实施例的电子设备的结构示意图。
需要说明的是,图2示出的电子设备的计算机系统200仅是一个示例,不应对本申请实施例的功能和使用范围带来任何限制。
如图2所示,计算机系统200包括中央处理单元(CPU)201,其可以根据存储在只读存储器(ROM)202中的程序或者从存储部分208加载到随机访问存储器(RAM)203中的程序而执行各种适当的动作和处理。在RAM 203中,还存储有系统操作所需的各种程序和数据。CPU 201、ROM 202以及RAM 203通过总线204彼此相连。输入/输出(I/O)接口205也连接至总线204。
以下部件连接至I/O接口205:包括键盘、鼠标等的输入部分206;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分207;包括硬盘等的存储部分208;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分209。通信部分209经由诸如因特网的网络执行通信处理。驱动器210也根据需要连接至I/O接口205。可拆卸介质211,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器210上,以便于从其上读出的计算机程序根据需要被安装入存储部分208。
特别地,根据本申请的实施例,下文参考流程图描述的过程可以被实现为计算机软件程序。例如,本申请的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,所述计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,所述计算机程序可以通过通信部分209从网络上被下载和安装,和/或从可拆卸介质211被安装。在所述计算机程序被中央处理单元(CPU)201执行时,执行本申请的方法和/或装置中限定的各种功能。
需要说明的是,本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中,计算机可读存储介质可以是任何包含或存储程序的有形介质,所述程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中,计算机 可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,所述计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、RF等等,或者上述的任意合适的组合。
附图中的流程图和框图,图示了按照本申请各种实施例的方法、装置和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的模块和/或单元可以通过软件的方式实现,也可以通过硬件的方式来实现,所描述的模块和/或单元也可以设置在处理器中。其中,这些模块和/或单元的名称在某种情况下并不构成对所述模块和/或单元本身的限定。
作为另一方面,本申请还提供了一种计算机可读介质,所述计算机可读介质可以是上述实施例中描述的电子设备中所包含的;也可以是单独存在,而未装配入所述电子设备中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被一个所述电子设备执行时,使得所述电子设备实现如下述实施例中所述的方法。例如,所述的电子设备可以实现如图3至图20任一实施例所示的各个步骤。
图3示意性示出了根据本申请的一实施例的多通道数据传输方法的流程图。
如图3所示,本申请实施方式提供的多通道数据传输方法可以包括以下步骤。本申请实施方式提供的方法例如可以由代理服务器执行,但本申请并不限定于此。
在步骤S310中,通过多通道并行接收多个上行数据包。
本申请实施例中,对通道的数量和类型并不进行限制,通道的数量可以根据客户端和代理服务器之间能够支持的通信通道的数量来确定,例如,可 以包括WiFi通道、3G/4G/5G通道、有线通道等中的至少两种。
本申请实施例中,每个上行数据包可以包括上行包头和目标业务数据包。其中,所述上行包头可以进一步包括上行内部通信包头和上行通道包头;其中,所述上行内部通信包头可以包括向代理服务器发送所述上行数据包的业务客户端地址。
在步骤S320中,解析所述多个上行数据包获得多个目标业务数据包和多个上行包头。
本申请实施例中,将每个上行数据包中的上行包头从上行数据包上去除,获得目标业务数据包。
在步骤S330中,根据所述多个上行包头对所述多个目标业务数据包进行去重处理。
其中,各上行包头包括各上行数据包的包序号。
在示例性实施例中,各上行包头还可以包括各上行数据包的通道标识和通道信息。其中,所述通道标识用于标识当前上行数据包是通过哪一条通道发送过来的。所述通道信息可以包括发送所述当前上行数据包的通道地址,例如WiFi通道的IP地址(Internet Protocol Address,互联网协议地址)或者端口。
在示例性实施例中,所述根据所述多个上行包头对所述多个目标业务数据包进行去重处理,可以包括:若(MaxSeqno-curSeqno)>recvThred,则丢弃目标业务数据包;若(MaxSeqno-curSeqno)<=recvThred且curSeqno不在未收包集合中,则丢弃相应目标业务数据包;若curSeqno>MaxSeqno,则保留目标业务数据包;若(MaxSeqno-curSeqno)<=recvThred,且包序号在所述未收包集合中,则保留相应目标业务数据包;其中,curSeqno为上行数据包的包序号,为客户端MaxSeqno最大收包序号,recvThred为第一阈值。
例如,假设所述第一阈值recvThred为10,若当前的客户端最大收包序号MaxSeqno为20,当前接收到的上行数据包的包序号curSeqno为5,则此时MaxSeqno-curSeqno=20-5=15>10,则此时将该包序号为5的上行数据包丢弃。
再例如,假设所述第一阈值recvThred为10,若当前的客户端最大收包序号MaxSeqno为20,当前接收到的上行数据包的包序号curSeqno为15,则此时MaxSeqno-curSeqno=20-15=5<10,且此时的未收包集合中不包括包序号15,则同样的将该包序号为15的上行数据包丢弃。
又例如,假设所述第一阈值recvThred为10,若当前的客户端最大收包序号MaxSeqno为20,当前接收到的上行数据包的包序号curSeqno为15,则此时MaxSeqno-curSeqno=20-15=5<10,且此时的未收包集合中包括包序号15,则将该包序号为15的上行数据包保留,同时将包序号15从所述未收包集合中删除。
在示例性实施例中,所述根据所述多个上行包头对所述多个目标业务数据包进行去重处理,可以包括:若上行数据包的包序号与序号队列中的包序号均不相同,则将上行数据包的包序号加入至所述序号队列,并保留相应目标业务数据包;若上行数据包的包序号与所述序号队列中的任意一个包序号相同,则丢弃相应目标业务数据包。
在示例性实施例中,所述方法还可以包括:根据通道标识判断上行数据包的通道类型;若上行数据包的包序号大于相应通道类型的通道最大收包序号,且相应通道信息与相应通道类型存储的通道信息不一致,则更新相应通道类型的通道信息。
在步骤S340中,将去重处理后保留的目标业务数据包发送给目标业务服务器。
在示例性实施例中,所述方法还可以包括:接收所述目标业务服务器响应于所述目标业务数据包生成的回复数据包;根据各通道类型最新的通道信息给所述回复数据包分别封装相应下行包头,生成多个下行数据包;将所述多个下行数据包通过所述多通道并行发送至业务客户端。
本申请实施方式提供的多通道数据传输方法,通过多通道并行接收多个上行数据包;并解析多个上行数据包获得多个目标业务数据包和多个上行包头;然后,根据多个上行包头对多个目标业务数据包进行去重处理;之后,将去重处理后保留的目标业务数据包发送给目标业务服务器;其中,各上行包头包括各上行数据包的包序号,一方面,通过多通道同时收包,可以保障目标业务数据包的传输稳定性和有效性;另一方面,通过对并行接收的上行数据包聚合去重后再转发给目标业务服务器,对目标业务服务器屏蔽了网络变化,目标业务服务器对不同网络环境的变化无感知,不对目标业务服务器的运行造成影响。
图4示意性示出了根据本申请的另一实施例的多通道数据传输方法的流程图。本申请实施方式提供的方法例如可以由业务客户端执行,但本申请并不限定于此。
如图4所示,本申请实施方式提供的多通道数据传输方法可以包括以下步骤。
在步骤S410中,获取目标业务数据包。
在示例性实施例中,所述获取目标业务数据包,可以包括:根据业务配置请求控制服务器,获取目标业务服务器信息;根据所述目标业务服务器信息设定过滤策略;根据所述过滤策略截获所述目标业务数据包。
在下面的实施例中,以所述控制服务器为云端控制服务器、所述目标业务服务器为游戏服务器、所述目标业务数据包为游戏数据包为例进行说明,但本申请并不限定于此,可以根据具体的应用场景进行相应的设置。
在步骤S420中,给所述目标业务数据包分别封装上行包头,形成多个上行数据包。
其中,各上行包头可以包括各上行数据包的包序号。
在步骤S430中,通过多通道并行发送所述多个上行数据包至代理服务器。
在示例性实施例中,所述方法还可以包括:通过所述多通道并行接收响应于所述目标业务数据包生成的多个下行数据包;解析所述多个下行数据包获得多个回复数据包和多个下行包头;根据所述多个下行包头对所述多个回复数据包进行去重处理。
图5示意性示出了根据本申请的一实施例的多通道数据传输系统的示意图。
如图5所示,本申请实施方式提供的多通道数据传输系统500可以包括业务客户端510、代理服务器520,业务客户端510和代理服务器520之间可以通过多通道例如可以通过通道1、通道2至通道n(其中n为大于等于2的正整数)进行数据的并行传输。
其中,业务客户端510可以配置为获取目标业务数据包,给所述目标业务数据包分别封装上行包头,形成多个上行数据包并发送。
代理服务器520可以配置为通过多通道并行接收所述多个上行数据包,解析所述多个上行数据包获得多个目标业务数据包和多个上行包头,根据所述多个上行包头对所述多个目标业务数据包进行去重处理,将去重处理后保留的目标业务数据包发送给目标业务服务器530。
在示例性实施例中,代理服务器520还可以配置为接收目标业务服务器530响应于所述目标业务数据包生成的回复数据包,根据各通道类型最新的通道信息给所述回复数据包分别封装相应下行包头,生成多个下行数据包并发送;业务客户端510还可以配置为通过所述多通道并行接收所述多个下行数据包,解析所述多个下行数据包获得多个回复数据包和多个下行包头,根据所述多个下行包头对所述多个回复数据包进行去重处理。
图6示意性示出了根据本申请的另一实施例的多通道数据传输系统的示意图。
如图6所示,本申请实施方式提供的多通道数据传输系统600可以包括业务客户端610、负载均衡服务器620和代理服务器630。其中,业务客户端610和代理服务器630可以参考上述图5实施例中的业务客户端510和代理服务器520,在此不再赘述。
与上述图5所示实施例的不同之处在于,本申请实施方式提供的多通道数据传输系统600还可以包括负载均衡服务器620。其中,负载均衡服务器 620可以配置为通过所述多通道并行接收所述多个上行数据包,并根据上行包头确定所述多个上行数据包的代理服务器,将所述多个上行数据包通过所述多通道并行发送至代理服务器630。
本申请实施例中,所述方法还可以包括:代理服务器630对所述多个上行数据包进行去重处理后,再将去重后的目标业务数据包发送至目标业务服务器640。或者代理服务器630还可以对目标业务服务器640响应于接收到的目标业务数据包返回的回复数据包进行处理,生成多个下行数据包,并通过通道1至通道n并行发送多个下行数据包至负载均衡服务器620,再通过负载均衡服务器620,通过通道1至通道n将所述多个下行数据包并行发送至业务客户端610。
下面通过具体的实例对上述方法和系统进行进一步的说明,但并不用于限制本申请。
图7示意性示出了根据本申请的一实施例的多通道数据传输方法的整体架构图。这里以WiFi和4G双通道来建立手机客户端与代理服务器之间的数据传输通道为例。但实际上本申请实施例提供的方法可以实现三通道或者更多通道。
双通道技术架构如图7所示,提供了一种基于WiFi和4G网络双通道同时发包的方法,本申请实施例提供的方法可以应用于客户端SDK(Software Development Kit,软件开发工具包)或客户端APP(application,应用)两种接入方式,在图7中以客户端APP 713为例进行说明,通过WiFi和4G双通道发送相同游戏数据包至代理服务器740聚合去重,然后将去重后的游戏数据包发送至游戏服务器750;代理服务器740收到游戏服务器750的回复数据包时,分别通过与客户端710建立的WiFi通道和4G通道发送此回复数据包,保障游戏数据包的传输稳定性,业务可零成本接入。
双通道的客户端逻辑可以包括以下步骤。
首先,在客户端710(例如手机客户端,但并不限定于此,可以是任意类型的终端设备)开启游戏客户端711和客户端APP 713。开启客户端APP 713后,客户端APP 713创建虚拟网卡7131,并建立两个线程绑定WiFi通道和4G通道。
本申请实施例中,客户端APP 713可以依据对应的游戏业务配置向云端控制服务器720发送请求,云端控制服务器720根据所述请求向客户端APP 713下发游戏服务器IP。客户端APP 713根据此游戏服务器IP设定iptables过滤策略,将游戏客户端711的游戏数据包从真实网卡712截获并转发至虚拟网卡7131。这是因为手机客户端还可能同时存在很多非游戏数据包的其他业务数据包,本申请实施例中可以仅将配置过的游戏数据包通过双通道发送,而那些非游戏数据包的其他业务数据包可以仍然采用单通道收 发,由此可以降低占用的网络流量。其中,进一步的,哪台游戏服务器或者哪些游戏数据包需要通过双通道收发,可以预先配置存储在云端控制服务器720中,客户端APP 713仅截获需要双通道发送的游戏数据包转发至虚拟网卡7131。
本申请实施例中,客户端APP 713从虚拟网卡7131接收到所述游戏数据包后,通过上行处理模块7132封装上行通道包头,形成两个上行数据包,将这两个上行数据包分别通过WiFi和4G两个通道发送至负载均衡服务器731和负载均衡服务器732。
本申请实施例中,封装的上行通道包头可以包括以下信息。
typedef struct MutiTunnelUPHead{
uint32_t m_bussId;//游戏标识
uint8_t ver;//填入主通道标识
uint8_t type;//通道标识,当前上行数据包的通道号或包类型
uint32_t seqno;//包序号
uint32_t clientKey;//客户端的唯一标识
uint32_t devKey;//手机设备唯一标识
uint32_t dst_ip;//目标ip
uint16_t dst_port;//目标port
uint8_t mutisetID;//主通道的运营商ID
}MutiTunnelUPHead;//新版协议代码;
其中,默认WiFi通道为主通道,若WiFi通道的通道号标记为0,则主通道标识为0,相应地,通道标识为0代表当前上行数据包的通道类型为WiFi通道,通道标识为1代表当前上行数据包的通道类型为4G通道。客户端的唯一标识clientkey可以采用hash32算法求出。
本申请实施例中,若WiFi通道和4G通道分属于不同的运营商,且WiFi通道为主通道,则主通道的运营商ID mutisetID字段为WiFi通道的运营商标识,可以用于确定代理服务器集群。
本申请实施例中,客户端APP 713还可以通过下行处理模块7133接收负载均衡服务器731从WiFi通道以及负载均衡服务器732从4G通道并行发送的多个下行数据包,通过下行处理模块7133将下行数据包中的下行包头去除后,并通过去重逻辑进行去重,依次通过虚拟网卡7131和真实网卡712发送给游戏客户端711。
本申请实施例中,所述下行包头可以包括以下信息:
typedef struct MutiTunnelDownHead{
uint32_t seqno;//包序号
char data[0];//包内容
}MutiTunnelDownHead;
图7中的负载均衡服务器731可以进一步包括代理服务映射模块7311、上行线程7312和下行线程7313;负载均衡服务器732可以进一步包括代理服务映射模块7321、上行线程7322和下行线程7323。代理服务器740可以进一步包括线程维护模块741,通信维护模块742,客户端1线程,客户端2线程,直至客户端n线程,其中假设客户端n线程743可以进一步包括下行处理模块7431和上行处理模块7432。具体的实现功能可以参照下述实施例。
需要说明的是,图7所示实施例中,以WiFi通道和4G通道由不同的运营商提供为例,因此需要两个负载均衡服务器731和732,类似的,若将本申请实施例提供的方法应用于三通道或更多通道,则所述多通道由几个运营商提供,则相应的需要几个负载均衡服务器。同理,若所述多通道均由同一个运营商提供,则可以只需一个负载均衡服务器。
此外,虽然图7中仅示出了一个代理服务器,但实际情况中,可以是一个代理服务器集群,本申请实施例中,通过所述负载均衡服务器将客户端通过多通道并行发送的多个上行数据包发送至同一个代理服务器中,就需要负载均衡服务器根据上行数据包的上行包头中的信息确定代理服务器集群中的同一个代理服务器(也可以称之为代理服务节点)。类似的,若所述多通道分别由多个运营商提供,则会有相应的多个代理服务器集群,此时,可以根据上行包头中的主通道标识来确定主通道对应的代理服务器集群作为用于确定所述同一个代理服务器的目标集群。
本申请实施方式提供的多通道数据传输方法,通过WiFi和4G两个通道同时发送相同的游戏数据包,只要其中一个网络通道的游戏数据包能够正常到达,则用户体验仍可保持正常,即对客户端-服务端数据收发网络通道进行容灾处理,可以有效预防WiFi或4G网络抖动引起的丢包和高延迟等问题。同时,通过代理服务器还可以向游戏客户端和游戏服务器屏蔽网络变化,游戏客户端和游戏服务器对不同网络环境的切换行为无感知,可以做到平滑切换。另一方面,本申请实施例提供的方法,在复杂的移动网络环境下,可以有效的提升实时游戏卡顿体验,在无线WiFi或4G网络较差的情况下,仍能很好的保障数据传输有效性,尤其对于常见的WiFi无线干扰,优化率可高达90%。
图8示意性示出了根据本申请的一实施例的客户端APP多通道发送上行数据包的示意图。
如图8所示,客户端APP 713中的虚拟网卡7131将游戏数据包发送至上行处理模块7132,上行处理模块7132给所述游戏数据包封装上行包头后,生成两个上行数据包,分别通过WiFi通道和4G通道将这两个上行数据包发送出去。
图9示意性示出了根据本申请的一实施例的客户端APP多通道接收下行数据包的示意图。
如图9所示,客户端APP 713中的下行处理模块7133根据下行包头对下行数据包进行去重处理,进而,将去重处理后去掉下行数据包中的下行包头后的游戏数据包发送至虚拟网卡7131,虚拟网卡7131转发至真实网卡712。
图10示意性示出了根据本申请的一实施例的数据包去重方法的流程图。需要说明的是,图10-12提供的两种数据包去重方法既可以适用于客户端,也可以适用于代理服务器端。
如图10所示,本申请实施例提供的数据包去重方法可以包括以下步骤。
在步骤S1001中,收到新包。
这里,对于客户端而言,收到的是一个新的下行数据包;对于代理服务器而言,收到的是一个新的上行数据包。
在步骤S1002中,判断该新包的包序号curSeqno是否比其通道最大收包序号大;若该新包的包序号curSeqno大于其通道最大收包序号,则进入步骤S1003;若该新包的包序号curSeqno小于等于其通道最大收包序号,则跳转到步骤S1006。
这里,假设收到的新包的包序号为curSeqno,根据其包头(上行包头或者下行包头)中的通道标识可以判断出该新包的通道类型,例如若该新包的通道标识为0,可以知道该新包是通过WiFi通道发送的,此时,该新包对应的WiFi通道最大收包序号可以获知,若该新包的包序号curSeqno大于WiFi通道最大收包序号,说明对于WiFi通道而言,这是一个新接收到的包。若该新包的包序号curSeqno小于等于WiFi通道最大收包序号,说明对于WiFi通道而言,这是一个之前已经接收过的包。
需要说明的是,本申请实施例中,通道最大收包序号是指对应通道之前收到过的最大包序号,但对于所述多通道而言,这个通道最大收包序号不一定等于下文中的客户端最大收包序号。
在步骤S1003中,更新其通道最大收包序号。
例如,若该新包来自WiFi通道,其包序号为2,而WiFi通道最大收包序号为1,则更新WiFi通道最大收包序号为2。
在步骤S1004中,判断该新包的通道信息是否与之前存储的其通道的通道信息一致;若该新包的通道信息与之前存储的其通道的通道信息不一致,则跳转到步骤S1006;若该新包的通道信息与之前存储的其通道的通道信息一致,则进入步骤S1005。
例如,若该新包相对于WiFi通道而言,是一个之前从未接收过的新包, 则此时可以判断该新包的通道信息例如通道地址是否与之前存储的WiFi通道的通道地址一致,若两者不一致,则更新WiFi通道的通道地址,这样可以保证存储的是最新的通道地址,从而可以保持客户端与代理服务器之间的正确连接。
在步骤S1005中,更新其通道的通道信息。
需要说明的是,上述步骤S1003和S1004可以并行执行。
在步骤S1006中,判断该新包的包序号curSeqno是否比客户端最大收包序号MaxSeqno大;若该新包的包序号curSeqno比所述客户端最大收包序号MaxSeqno大,则进入步骤S1007。
需要说明的是,本申请实施例中,所述客户端最大收包序号MaxSeqno是指WiFi通道和4G通道之前收到的被保留并被转发的最大包序号。
若curSeqno>MaxSeqno,说明该新包是之前从未接收过的新包,此时将该新包保留。
在步骤S1007中,将该新包的包序号curSeqno与所述客户端最大收包序号MaxSeqno之间跳过的包序号放入未收包集合中。
本申请实施例中,按照时间排序依次发送的包,到达时间并不一定一致,例如包序号大的包后发送但反而有可能先到,此时该新包的包序号有可能比所述客户端最大收包序号MaxSeqno大1以上,例如,若MaxSeqno等于1,curSeqno为4,则4-1=3>1,即跳过了包序号为2和3的包还未接收,此时将包序号2和3放入未收包集合中。
在步骤S1008中,判断所述未收包集合的大小size是否大于第一阈值recvThred;若size>recvThred,则进入步骤S1009;若size<=recvThred,则跳转到步骤S1011。
例如,所述第一阈值可以设置为10。但本申请并不限定于此。
在步骤S1009中,将最小几个未收包序号从所述未收包集合中删除。
该步骤的目的是为了限制未收包集合的大小,保持未收包集合内的包序号数量在所述第一阈值范围内。
在步骤S1010中,更新所述客户端最大收包序号MaxSeqno。
在步骤S1011中,保留转发此包。
需要说明的是,上述步骤S1009、S1010和S1011之间可以没有执行先后顺序,可以并行执行。
在步骤S1012中,判断所述客户端最大收包序号MaxSeqno减去该新包的包序号的差值是否大于所述第一阈值;若(MaxSeqno-curSeqno)<=recvThred,则进入步骤S1013;若(MaxSeqno-curSeqno)>recvThred,则跳转到步骤S1015。
本申请实施例中,如果该新包的包序号比所述客户端最大收包序号MaxSeqno小第一阈值recvThred,则丢弃该新包。
例如,假设该新包的包序号为7,所述客户端最大收包序号MaxSeqno为20,第一阈值recvThred为10,则20-7=13>10,此时将包序号为7的该新包丢弃。
需要说明的是,这个第一阈值的取值是可以调整的,其目的是为了限制代理服务器或者客户端等待某一个包的时长,此时可以忍受一定数量的丢包。如果响应级别高,可以将所述第一阈值设置小一些,例如为10;如果响应级别低,可以将所述第一阈值设置大一些,例如为100。甚至,还可以将所述第一阈值设置为所有包序号中的最大值也是可以的,此时相当于可以无限等待,不会丢包。
在步骤S1013中,判断该新包的包序号curSeqno是否在所述未收包集合中;若该新包的包序号curSeqno在所述未收包集合中,则进入步骤S1014;若该新包的包序号curSeqno不在所述未收包集合中,则跳转到步骤S1015。
在步骤S1014中,将该新包的包序号curSeqno从所述未收包集合中删除,跳转到步骤S1011,保留该新包并将其转发。
还是以所述客户端最大收包序号MaxSeqno为20,第一阈值recvThred为10为例,假设该新包的包序号为17,这时20-17=3<10,且之前未接收过包序号为17的包,即未收包集合中17这个包序号,则接收该新包。反之,若之前接收过包序号为17的包,即未收包集合中没有17这个包序号,同样丢弃该新包。
在步骤S1015中,丢弃该新包。
在示例性实施例中,所述方法还可以包括:更新各个通道先到达包数量,以及各个通道到达包数量,从而可以将其用于统计各个通道的数据传输效果。
图11示意性示出了基于图10所示数据包去重方法的一个实例的示意图。
如图11所示,假设WiFi通道的客户端发送序列的包序号依次为1、2、3、4,4G通道的客户端发送序列的包序号也依次为1、2、3、4,代理服务器接收序列的包序号依次为WiFi通道的1、4G通道的1、WiFi通道的4、4G通道的2、WiFi通道的2和3、4G通道的3和4。
这里,假设代理服务器首先接收到WiFi通道的包序号为1的包,保留并转发此包,更新MaxSeqno=1。
接着,代理服务器接收到4G通道的包序号为1的包。此时对应情况(case)1:MaxSeqno=1,MaxSeqno=curSeqno,丢弃此包。
接着,代理服务器接收到WiFi通道的包序号为4的包。此时对应情况(case)2:MaxSeqno=1,MaxSeqno<curSeqno&curSeqno-MaxSeqno>1,更新MaxSeqno=4,将跳过的包序号2和3放入未收包集合中,保留此包。
接着,代理服务器接收到4G通道的包序号为2的包。此时对应情况(case)3:MaxSeqno=4,MaxSeqno>curSeqno&MaxSeqno-curSeqno<10,在所述未收包集合中查找到包序号2,保留此包,并将其从所述未收包集合中删除,未收包集合中只剩下包序号3。
最终,代理服务器转发序列的包序号依次为WiFi通道的1、WiFi通道的4、4G通道的2、WiFi通道的3。
图12示意性示出了根据本申请的另一实施例的数据包去重方法的流程图。
如图12所示,本申请实施例提供的数据包去重方法可以包括以下步骤。
在步骤S1201中,收到新包。
在步骤S1202中,判断序号队列是否为空;若所述序号队列为空,则跳转到步骤S1208;若所述序号队列不为空,则进入步骤S1203。
本申请实施例中,若该客户端对应的序号队列为空,则在该序号队列中加入该新包的包序号和此时的时间戳,保留并转发此包。
在步骤S1203中,正向遍历所述序号队列。
在步骤S1204中,将超时包序号从所述序号队列中删除。
本申请实施例中,若所述序号队列不为空,正向遍历所述序号队列,确定序号队列中加入时间与当前时间的时间差超过第二阈值(例如500ms)的包序号,将该包序号及其时间戳从所述序号队列中移除。
需要说明的是,所述第二阈值也是一个可以调整的值,具体看维护这个序号队列的时长限制,避免这个队列中包序号太多。这种做法可能导致例如500ms之前接收的包序号,由于在序号队列中被移除,500ms之后重新收取相同的包序号,即可能重复收包,但不会丢包。
在步骤S1205中,反向遍历所述序号队列。
需要说明的是,上述步骤中的正向遍历和反向遍历仅是为了节省执行时间,实际对此不作限定。
在步骤S1206中,判断该新包的包序号是否在所述序号队列中;若该新包的包序号在所述序号队列里,则进入步骤S1207。
在步骤S1207中,丢弃此新包。
若所述序号队列中的某个包序号与该新包的包序号相同,则丢弃该新包。
在步骤S1208中,在所述序号队列中加入该新包的包序号和此时的时间戳。
如果所述序号队列中的所有序号与该新包的包序号都不相同,则在所述序号队列中加入该新包的包序号和此时的时间戳,保留并转发此新包。
在步骤S1209中,保留转发此新包。
需要说明的,本申请实施例中,去重逻辑并不限定为上述例举的两种方法,可以根据实际情况采用任意适当的去重方法对包进行去重。
图13示意性示出了根据本申请的一实施例的负载均衡服务器的示意图。
外网用户接入时,会存在WiFi和4G跨网(不同运营商之间)的情况,例如:假设WiFi宽带运营商为移动,4G运营商为电信。为解决此问题,需要在双通道后台接入层提供负载均衡服务。
如图13所示,为双通道的服务端中的负载均衡服务器逻辑,这里以负载均衡服务器731为例进行举例说明。
客户端APP把WiFi通道或4G通道的上行数据包发送到相应运营商接入点。
负载均衡服务器731通过WiFi通道接收到上行数据包,此时,所述上行数据包包括上行通道包头和游戏数据包,负载均衡服务器731解析上行通道包头,获得包头中的clientkey值和mutisetID字段对应的主通道的运营商ID,从而可以获知要将接收到的上行数据包发送到哪个运营商的代理服务器集群中的代理服务器。具体的,负载均衡服务器731中的代理服务映射模块7311可以根据clientkey值计算出代理服务节点。
本申请实施例中,负载均衡服务器731中的上行线程7312给前述接收到的上行数据包进一步封装上行内部通信包头,形成包括所述上行内部通信包头和所述上行通道包头以及所述游戏数据包的上行数据包,并将其转发至上述计算出的代理服务器740。
本申请实施例中,所述上行内部通信包头中可以存放客户端地址信息。例如:
typedef struct InerPkg{
struct sockaddr_in clientInfo;//客户端地址信息
char data[0];
}InerPkg;
图14示意性示出了根据本申请的一实施例的负载均衡服务器与代理服务器内部交互逻辑时序图。
如图14所示,步骤S1:客户端通过各通道发送上行数据包至负载均衡服务器,具体发送至负载均衡服务器的上行线程监控端口19000(举例说明,并不限定于此)。
步骤S2:负载均衡服务器内的代理服务映射模块同redis双向通信,获取最新的代理服务节点信息,同时,代理服务映射模块根据接收到的上行数据包的上行通道包头中的clientkey,计算当前接收到的上行数据包应该发向 的客户端专属代理服务节点。
本申请实施例中,redis可以看成是一个数据库。由于代理服务器集群中的代理服务器可能会发生改变,例如新增代理服务器、删除旧的代理服务器或者替换原有代理服务器,因此,为了代理服务映射模块能够计算得到准确的专属代理服务节点,需要将这些最新的代理服务器信息存储至redis中,然后负载均衡服务器的代理服务映射模块在计算当前包要转发到的代理服务节点时,读取redis中最新的代理服务器信息来计算。
需要说明的是,用于存储代理服务器信息的存储装置并不限于redis,可以是其他任意类型的存储设备。
步骤S3:负载均衡服务器在接收到的上行数据包基础上,继续封装上行内部通信包头,并将其向步骤S2查找到的专属代理服务节点转发。
步骤S4:通过代理服务器的主线程创建客户端专属线程,通过所述客户端专属线程去掉所述上行数据包的上行内部通信包头和上行通道包头,并将去重后的上行数据包中的游戏数据包发送至游戏服务器。
本申请实施例中,代理服务器会给每个客户端开启一个专属线程,用于监听每个客户端和游戏服务器是否有新的包发送过来。
步骤S5:代理服务器通过所述客户端专属线程,接收所述游戏服务器响应于其接收到的游戏数据包返回的回复数据包。
步骤S6:代理服务器给所述回复数据包封装下行内部通信包头和下行通道包头后形成下行数据包,并向各通道回发下行数据包至负载均衡服务器。
步骤S7:负载均衡服务器通过19001端口将下行数据包向各通道发送至所述客户端。
图15示意性示出了根据本申请的一实施例的负载均衡服务器的代理服务映射模块的示意图。
本申请实施例中,所述代理服务映射模块按运营商将代理服务器分几个集群,例如:电信、移动、联通和中小宽带运营商四个集群。所述代理服务映射模块将每个集群的N(N为大于等于0的整数)个代理服务节点均匀分配在0~4294967295(这个数值仅用于举例说明,本申请并不限定于此)范围内。
本申请实施例中,以clientkey值计算出相应的代理服务节点,计算公式可以如下:
svrNum(双通道代理节点数)//这里假设为4
MAX//最大值,这里假设为=4294967295
svrInterval=MAX/svrNum//这里假设为1073741823.75;
index=(clientkey/svrInterval)%svrNum;//%为求余运算
其中,index即为计算出来的代理节点编号,每个节点编号代表一个代理服务器的地址。
如图15所示:
0<=clientkey<1073741823,落在0节点;
1073741823<=clientkey<2147483647,落在1节点;
2147483647<=clientkey<3221225471,落在2节点;
3221225471<=clientkey<4294967295,落在3节点。
本申请实施例中,每个客户端有一个专属线程,即同一次传输通道建立后,WiFi通道和4G通道发送的多个上行数据包的clientkey值均是相同的。若本次传输通道断开后,同一客户端重新建立传输通道后,clientkey值会发生改变。
本申请实施例中,为了保证代理服务器可以平行在线动态扩容,从而可以随着收发数据包增加而扩充代理服务器,代理服务映射模块每隔预定时间例如每秒访问redis集群,获取最新的代理服务器列表。如果与最新代理服务器节点不一致,则完成增、删或替换的操作。
图16示意性示出了根据本申请的另一实施例的负载均衡服务器的代理服务映射模块的示意图。
如图16所示,为节点更新逻辑的举例说明。假设在节点3后增加节点4,根据上述的计算index的公式,因为svrInterval是等间隔的,所以这里需要在原有的每个节点后增加一个虚拟节点,例如增加虚拟节点0、1、2,来保持上述节点计算公式的一致性。其中,虚拟节点与其前一个节点代表的代理服务器地址信息是相同的,此时节点数量svrNum翻倍,例如svrNum等于8。
需要说明的是,新增节点可以在任意位置新增,不限于在节点3后增加。
图17示意性示出了根据本申请的又一实施例的负载均衡服务器的代理服务映射模块的示意图。
如图17所示,删除代理服务节点的一个实例。假设删除节点3,则需要增加一个虚拟节点2来补上删除的位置,同理是为了保持等间隔特性,虚拟节点地址信息与前一个节点相同。
图18示意性示出了根据本申请的再一实施例的负载均衡服务器的代理服务映射模块的示意图。
如图18所示,为替换代理服务节点的一个实例。假设替换旧节点3,则将节点3更换为新的节点4的信息即可。例如某台代理服务器性能退化,用新的代理服务器替换。
图19示意性示出了根据本申请的一实施例的代理服务器的逻辑时序图。
如图19所示,步骤S1:代理服务器接收上行数据包。
步骤S2:代理服务器脱去所述上行数据包的上行通道包头和上行内部通信包头并去重后,将游戏数据包发送至游戏服务器。同时,代理服务器更新线程维护模块,为此客户端在代理服务器处创建一个专属线程进行服务,并更新线程维护模块中的信息。
本申请实施例中,代理服务器新接收到一个客户端发送的上行数据包时,脱去所述上行数据包的上行通道包头和上行内部通信包头,获得客户端地址信息,并将其记录在通信维护模块,如此保证后续线程维护模块在封装下行包头时,可以从所述通信维护模块中复制一份相应的客户端地址信息,封装到下行内部通信包头中,从而可以让代理服务器获知下行数据包要转发到哪一个客户端。
本申请实施例中,客户端实时向代理服务器发送上行数据包所在通道信息,以方便代理服务器进行通道切换,从而可以保证在4G或者WiFi通道发生异常切换时,代理服务器可以在第一时间更新客户端对应的通道信息。此通道信息维护的通道包头ver和type字段。
需要说明的是,上述通道切换主要是指4G内部切换或者WiFi内部切换,因为4G地址和WiFi地址是可能变换的,因此,本申请实施例可以根据最新的通道信息保持客户端和代理服务器之间的连接。
还有一种异常情况是指例如WiFi为主通道,若WiFi发生异常无法联网,此时可以将4G切换为主通道,相应的改变通道包头ver字段,此时可以仅通过4G通道将下行数据包发送至客户端,但此时仍可使用WiFi对应运营商的代理服务器集群中的代理服务器完成封装下行包头等操作,可以不切换至4G运营商的代理服务器集群。
本申请实施例中,代理服务器可以依据上行数据包中的上行通道包头的客户端的唯一标识clientkey值,识别从4G和WiFi通道发送来的客户端数据,并进行去重处理,去重算法可以参照上述图10-12实施例。
本申请实施例中,代理服务器为客户端与游戏服务器建立一个唯一链接,将去重后的游戏数据包发送至所述游戏服务器。
步骤S3:游戏服务器响应于所述游戏数据包返回回复数据包。
步骤S4:代理服务器从通信维护模块中获取客户端地址并封装至所述回复数据包的下行内部通信包头,并给所述回复数据包封装下行通道包头然后转发。
本申请实施例中,代理服务器创建的客户端线程监听其与游戏服务器建立的专有链接,在收到游戏服务器返回的回复数据包后,依据所述通信维护 模块中其最新的WiFi通道和4G通道的地址信息,封装下行通道包头和下行内部通信包头后,将形成的两个下行数据包分别向两个通道发送。
本申请实施例中,代理服务器还可以定时进行客户端通道信息清理,如在超时时间内没有客户端数据从代理服务器经过,则将此客户端的线程和通道信息数据清除。
图20示意性示出了根据本申请的一实施例的代理服务器多通道发送下行数据包的示意图。
如图20所示,代理服务器740分别通过WiFi通道和4G通道,将封装有下行内部通信包头和下行通道包头的回复数据包即下行数据包分别发送至负载均衡服务器731和负载均衡服务器732。
负载均衡服务器731去掉所述下行数据包的下行内部通信包头后,通过WiFi通道将其发送至业务客户端(图中未示出)。
负载均衡服务器732去掉所述下行数据包的下行内部通信包头后,通过4G通道将其发送至业务客户端(图中未示出)。
本申请实施例中,负载均衡服务器中的下行线程接收到代理服务器发送的下行数据包后,将下行内部通信包头去除,并获取到客户端地址信息,将包括下行通道包头和回复数据包的下行数据包向业务客户端转发。
本方案中双通道负载均衡服务器最主要的作用是通过代理服务映射模块将wifi通道和4g通道的不同运营商的数据包发送到同一个双通道代理服务器,有几个运营商就有对应的几个双通道代理服务器集群,但是本方案中可以只需要用到主通道(默认为wifi通道)对应的运营商的双通道代理服务器集群,即使后续可能发生wifi通道异常关闭的情况,通过ver和type字段改变主通道为4g通道,此时由于加速已完成,初始化已完成,还是通过wifi通道对应的运营商的双通道代理服务器集群来发送下行数据包。在一些情况下,下行包可以只通过主通道来发送,但本方案中下行包是通过双通道来发送的。
本申请实施方式提供的方法较为灵活,大多数业务可零成本接入,无须业务做任何变动和适配。同时,发生WiFi或者4G上层网络故障时,用户完全无感知,且可预防70%以上的客户端卡顿情况,尤其在WiFi网络较为复杂情况下,效果较为显著。
以下介绍本申请的装置实施例,可以用于执行本申请上述的多通道数据传输方法。对于本申请装置实施例中未披露的细节,请参照本申请上述的多通道数据传输方法的实施例。
图21示意性示出了根据本申请的一实施例的多通道数据传输装置的框图。
如图21所示,本申请实施方式提供的多通道数据传输装置2100可以包括上行数据接收模块2110、上行数据解析模块2120、上行数据去重模块2130以及上行数据转发模块2140。
其中,上行数据接收模块2110,用于通过多通道并行接收多个上行数据包。
上行数据解析模块2120,用于解析所述多个上行数据包获得多个目标业务数据包和多个上行包头。
上行数据去重模块2130,用于根据所述多个上行包头对所述多个目标业务数据包进行去重处理。
上行数据转发模块2140,用于将去重后保留的目标业务数据包发送给目标业务服务器。
其中,各上行包头可以包括各上行数据包的包序号。
在示例性实施例中,上行数据去重模块2130可以包括:第一丢包单元,用于若(MaxSeqno-curSeqno)>recvThred,则丢弃相应目标业务数据包;若(MaxSeqno-curSeqno)<=recvThred,且curSeqno不在未收包集合中,则丢弃相应目标业务数据包。
在示例性实施例中,上行数据去重模块2130还可以包括:第一留包单元,用于若curSeqno>MaxSeqno,则保留相应目标业务数据包;若(MaxSeqno-curSeqno)<=recvThred,且包序号在所述未收包集合中,则保留相应目标业务数据包。
其中,curSeqno为上行数据包的包序号,MaxSeqno为客户端最大收包序号,recvThred为第一阈值。
在示例性实施例中,上行数据去重模块2130可以包括:第二留包单元,用于若上行数据包的包序号与序号队列中的包序号均不相同,则将上行数据包的包序号加入至所述序号队列,并保留相应目标业务数据包;第二丢包单元,用于若上行数据包的包序号与所述序号队列中的任意一个包序号相同,则丢弃相应目标业务数据包。
在示例性实施例中,各上行包头还包括各上行数据包的通道标识和通道信息。
在示例性实施例中,多通道数据传输装置2100还可以包括:通道类型判断模块,用于根据通道标识判断上行数据包的通道类型;通道信息更新模块,用于若上行数据包的包序号大于相应通道类型的通道最大收包序号,且相应通道信息与相应通道类型存储的通道信息不一致,则更新相应通道类型的通道信息。
在示例性实施例中,多通道数据传输装置2100还可以包括:回复数据接收模块,用于接收所述目标业务服务器响应于所述目标业务数据包生成的回复数据包;下行数据生成模块,用于根据各通道类型最新的通道信息给所 述回复数据包分别封装相应下行包头,生成多个下行数据包;下行数据发送模块,用于将所述多个下行数据包通过所述多通道并行发送至业务客户端。
图22示意性示出了根据本申请的另一实施例的多通道数据传输装置的框图。
如图22所示,本申请实施方式提供的多通道数据传输装置2200可以包括:目标数据获取模块2210、上行包头封装模块2220以及上行数据发送模块2230。
其中,目标数据获取模块2210,用于获取目标业务数据包。
上行包头封装模块2220,用于给所述目标业务数据包分别封装上行包头,形成多个上行数据包。
上行数据发送模块2230,用于通过多通道并行发送所述多个上行数据包至代理服务器。
其中,各上行包头可以包括各上行数据包的包序号。
在示例性实施例中,多通道数据传输装置2200还可以包括:下行数据接收模块,用于通过所述多通道并行接收响应于所述目标业务数据包生成的多个下行数据包;下行数据解析模块,用于解析所述多个下行数据包获得多个回复数据包和多个下行包头;下行数据去重模块,用于根据所述多个下行包头对所述多个回复数据包进行去重处理。
在示例性实施例中,目标数据获取模块2210包括:业务服务器信息获取单元,用于根据业务配置请求控制服务器,获取目标业务服务器信息;过滤策略设定单元,用于根据所述目标业务服务器信息设定过滤策略;目标业务数据截获单元,用于根据所述过滤策略截获所述目标业务数据包。
应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。实际上,根据本申请的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。因此,根据本申请实施方式的技术方案可以以软件产品的形式体现出来,所述软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。
本领域技术人员在考虑说明书及实践这里公开的申请后,将容易想到本 申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (15)

  1. 一种多通道数据传输方法,应用于代理服务器,包括:
    通过多通道并行接收多个上行数据包;
    解析所述多个上行数据包获得多个目标业务数据包和多个上行包头;
    根据所述多个上行包头对所述多个目标业务数据包进行去重处理;
    将去重处理后保留的目标业务数据包发送给目标业务服务器;
    其中,各上行包头包括各上行数据包的包序号。
  2. 根据权利要求1所述的方法,所述根据所述多个上行包头对所述多个目标业务数据包进行去重处理,包括:
    若(MaxSeqno-curSeqno)>recvThred,则丢弃相应目标业务数据包;若(MaxSeqno-curSeqno)<=recvThred,且curSeqno不在未收包集合中,则丢弃相应目标业务数据包;
    若curSeqno>MaxSeqno,则保留相应目标业务数据包;
    若(MaxSeqno-curSeqno)<=recvThred,且curSeqno在所述未收包集合中,则保留相应目标业务数据包;
    其中,curSeqno为上行数据包的包序号,MaxSeqno为客户端最大收包序号,recvThred为第一阈值。
  3. 根据权利要求1所述的方法,所述根据所述多个上行包头对所述多个目标业务数据包进行去重处理,包括:
    若上行数据包的包序号与序号队列中的包序号均不相同,则将上行数据包的包序号加入至所述序号队列,并保留相应目标业务数据包;
    若上行数据包的包序号与所述序号队列中的任意一个包序号相同,则丢弃相应目标业务数据包。
  4. 根据权利要求1所述的方法,各上行包头还包括各上行数据包的通道标识和通道信息;所述方法还包括:
    根据通道标识判断上行数据包的通道类型;
    若上行数据包的包序号大于相应通道类型的通道最大收包序号,且相应通道信息与相应通道类型存储的通道信息不一致,则更新相应通道类型的通道信息。
  5. 根据权利要求4所述的方法,所述方法还包括:
    接收所述目标业务服务器响应于所述目标业务数据包生成的回复数据包;
    根据各通道类型最新的通道信息给所述回复数据包分别封装相应下行包头,生成多个下行数据包;
    将所述多个下行数据包通过所述多通道并行发送至业务客户端。
  6. 一种多通道数据传输方法,应用于业务客户端,包括:
    获取目标业务数据包;
    给所述目标业务数据包分别封装上行包头,形成多个上行数据包;
    通过多通道并行发送所述多个上行数据包至代理服务器;
    其中,各上行包头包括各上行数据包的包序号。
  7. 根据权利要求6所述的方法,还包括:
    通过所述多通道并行接收响应于所述目标业务数据包生成的多个下行数据包;
    解析所述多个下行数据包获得多个回复数据包和多个下行包头;
    根据所述多个下行包头对所述多个回复数据包进行去重处理。
  8. 根据权利要求6所述的方法,所述获取目标业务数据包,包括:
    根据业务配置请求控制服务器,获取目标业务服务器信息;
    根据所述目标业务服务器信息设定过滤策略;
    根据所述过滤策略截获所述目标业务数据包。
  9. 一种多通道数据传输装置,包括:
    上行数据接收模块,用于通过多通道并行接收多个上行数据包;
    上行数据解析模块,用于解析所述多个上行数据包获得多个目标业务数据包和多个上行包头;
    上行数据去重模块,用于根据所述多个上行包头对所述多个目标业务数据包进行去重处理;
    上行数据转发模块,用于将去重后保留的目标业务数据包发送给目标业务服务器;
    其中,各上行包头包括各上行数据包的包序号。
  10. 一种多通道数据传输装置,包括:
    目标数据获取模块,用于获取目标业务数据包;
    上行包头封装模块,用于给所述目标业务数据包分别封装上行包头,形成多个上行数据包;
    上行数据发送模块,用于通过多通道并行发送所述多个上行数据包至代理服务器;
    其中,各上行包头包括各上行数据包的包序号。
  11. 一种多通道数据传输系统,包括:
    业务客户端,配置为获取目标业务数据包,给所述目标业务数据包分别封装上行包头,形成多个上行数据包并发送;
    代理服务器,配置为通过多通道并行接收所述多个上行数据包,解析所述多个上行数据包获得多个目标业务数据包和多个上行包头,根据所述多个上行包头对所述多个目标业务数据包进行去重处理,将去重处理后保留的目标业务数据包发送给目标业务服务器。
  12. 根据权利要求11所述的系统,其中:
    所述代理服务器还配置为接收所述目标业务服务器响应于所述目标业 务数据包生成的回复数据包,根据各通道类型最新的通道信息给所述回复数据包分别封装相应下行包头,生成多个下行数据包并发送;
    所述业务客户端还配置为通过所述多通道并行接收所述多个下行数据包,解析所述多个下行数据包获得多个回复数据包和多个下行包头,根据所述多个下行包头对所述多个回复数据包进行去重处理。
  13. 根据权利要求11或12所述的系统,还包括:
    负载均衡服务器,配置为通过所述多通道并行接收所述多个上行数据包,并根据上行包头确定所述多个上行数据包的代理服务器,将所述多个上行数据包通过所述多通道并行发送至所述代理服务器。
  14. 一种计算机可读介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现如权利要求1至5中任一项所述的方法;或者,所述计算机程序被处理器执行时实现如权利要求6至8中任一项所述的方法。
  15. 一种电子设备,其特征在于,包括:
    一个或多个处理器;
    存储装置,配置为存储一个或多个计算机程序,当所述一个或多个计算机程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现如权利要求1至5中任一项所述的方法;或者,使得所述一个或多个处理器实现如权利要求6至8中任一项所述的方法。
PCT/CN2019/092467 2018-08-15 2019-06-24 多通道数据传输方法及装置 WO2020034758A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2021510518A JP7174834B2 (ja) 2018-08-15 2019-06-24 マルチ・チャネル・データ伝送方法、装置及びシステム並びにコンピュータ・プログラム、電子機器
EP19850324.5A EP3758412B1 (en) 2018-08-15 2019-06-24 Multichannel data transmission method, apparatus, system and computer-readable medium
US17/017,531 US11350318B2 (en) 2018-08-15 2020-09-10 Multichannel data transmission method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810931095.7A CN110167084B (zh) 2018-08-15 2018-08-15 多通道数据传输方法及装置
CN201810931095.7 2018-08-15

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/017,531 Continuation US11350318B2 (en) 2018-08-15 2020-09-10 Multichannel data transmission method and apparatus

Publications (1)

Publication Number Publication Date
WO2020034758A1 true WO2020034758A1 (zh) 2020-02-20

Family

ID=67645119

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/092467 WO2020034758A1 (zh) 2018-08-15 2019-06-24 多通道数据传输方法及装置

Country Status (5)

Country Link
US (1) US11350318B2 (zh)
EP (1) EP3758412B1 (zh)
JP (1) JP7174834B2 (zh)
CN (1) CN110167084B (zh)
WO (1) WO2020034758A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112436928A (zh) * 2020-11-23 2021-03-02 北京中航通用科技有限公司 一种数据传输的方法及装置
CN113905350A (zh) * 2021-08-27 2022-01-07 华人运通(上海)自动驾驶科技有限公司 数据上行、下行传输方法、车载智能终端、服务器及系统

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020063905A1 (en) 2018-09-28 2020-04-02 Suteng Innovation Technology Co., Ltd. Range-finding system and method for data communication within the same
CN110677394B (zh) * 2019-09-12 2022-03-29 视联动力信息技术股份有限公司 一种多媒体数据的传输方法及系统
WO2021061157A1 (en) * 2019-09-27 2021-04-01 Viasat, Inc. Method and apparatus for distributing network traffic over multiple communication networks
CN112751772B (zh) * 2019-10-31 2023-01-24 上海哔哩哔哩科技有限公司 数据传输方法和系统
CN111147359B (zh) * 2019-12-31 2021-10-29 珠海市小源科技有限公司 适用于多通道的消息转换方法、装置及存储介质
CN111200830B (zh) * 2020-01-02 2022-04-26 腾讯科技(深圳)有限公司 数据传输方法及装置、电子设备
CN111479293B (zh) * 2020-04-16 2023-07-25 展讯通信(上海)有限公司 数据处理方法及装置
CN111586730B (zh) * 2020-05-27 2021-03-16 中铁电气化局集团有限公司 一种应用于轨道交通的无线通信方法及系统
CN111835448B (zh) * 2020-07-27 2022-05-24 上海挚想科技有限公司 多通道的通信时序控制方法及系统
CN112541036B (zh) * 2020-11-24 2023-12-12 南方电网数字电网研究院有限公司 电网数据同步方法、系统、装置、计算机设备和存储介质
CN113452624B (zh) * 2021-04-07 2024-04-23 苏州瑞立思科技有限公司 一种可动态切换的多通道选路系统的应用方法
CN113259256B (zh) * 2021-07-15 2021-09-21 全时云商务服务股份有限公司 一种重复数据包过滤方法、系统及可读存储介质
CN114157730B (zh) * 2021-10-26 2024-07-09 武汉光迅信息技术有限公司 一种报文去重的方法和装置
CN115378454B (zh) * 2022-08-04 2024-07-16 成都索骥科技有限公司 一种多通道数据链路通信系统
CN115334174B (zh) * 2022-08-22 2024-02-06 卡斯柯信号有限公司 一种基于Subset-037协议的多通道匹配方法及通信方法
CN117062257B (zh) * 2023-10-11 2024-02-09 腾讯科技(深圳)有限公司 基于多通道的数据传输方法、终端设备以及目标网关
CN117201551B (zh) * 2023-11-06 2024-01-30 中交一公局集团有限公司 一种基于物联网的建筑信息处理方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130064198A1 (en) * 2011-09-14 2013-03-14 Qualcomm Incorporated Multipath transport tunnel over multiple air interfaces connecting wireless stations
CN104753627A (zh) * 2013-12-26 2015-07-01 中兴通讯股份有限公司 多路径传输方法、系统及数据发送装置和数据接收装置
CN106559840A (zh) * 2016-11-16 2017-04-05 北京邮电大学 一种多协议混合通信方法及系统

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090031419A1 (en) * 2001-05-24 2009-01-29 Indra Laksono Multimedia system and server and methods for use therewith
GB2399980A (en) * 2003-03-26 2004-09-29 Zarlink Semiconductor Ltd Packet buffer management
WO2012165794A2 (ko) * 2011-06-03 2012-12-06 에스케이 텔레콤주식회사 이기종 네트워크 기반 데이터 동시 전송 서비스 시스템 및 그 방법
CN102291856A (zh) * 2011-09-21 2011-12-21 大连钜正科技有限公司 一种支持多通道多信道的物联网网关
CN104683295B (zh) * 2013-11-27 2020-02-14 中兴通讯股份有限公司 数据包过滤规则配置方法、装置及系统
US9871720B1 (en) * 2014-03-18 2018-01-16 Amazon Technologies, Inc. Using packet duplication with encapsulation in a packet-switched network to increase reliability
EP3143742B1 (en) * 2014-05-15 2020-07-08 Telefonaktiebolaget LM Ericsson (publ) Method and devices for controlling usage of multi-path tcp
CN104967502B (zh) * 2015-02-03 2017-06-27 深圳市腾讯计算机系统有限公司 数据发送方法和装置、数据接收方法和装置
WO2016130054A1 (en) * 2015-02-09 2016-08-18 Telefonaktiebolaget Lm Ericsson (Publ) Method and device for handling multi path connections
JP2017028589A (ja) 2015-07-24 2017-02-02 富士通株式会社 通信装置、無線通信装置、および通信方法
US20170279738A1 (en) * 2016-03-25 2017-09-28 Le Holdings(Beijing)Co., Ltd Method, apparatus, and system for transmitting data
US10764781B2 (en) * 2016-05-03 2020-09-01 Qualcomm Incorporated Systems and methods for reordering data received from a plurality of radio access technologies (RATs)
CN108207014A (zh) 2016-12-19 2018-06-26 中科院-南京宽带无线移动通信研发中心 多通道通信系统及其方法
WO2019036217A1 (en) * 2017-08-18 2019-02-21 Missing Link Electronics, Inc. HETEROGENEOUS TRANSPORT BASED ON PACKETS

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130064198A1 (en) * 2011-09-14 2013-03-14 Qualcomm Incorporated Multipath transport tunnel over multiple air interfaces connecting wireless stations
CN104753627A (zh) * 2013-12-26 2015-07-01 中兴通讯股份有限公司 多路径传输方法、系统及数据发送装置和数据接收装置
CN106559840A (zh) * 2016-11-16 2017-04-05 北京邮电大学 一种多协议混合通信方法及系统

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112436928A (zh) * 2020-11-23 2021-03-02 北京中航通用科技有限公司 一种数据传输的方法及装置
CN112436928B (zh) * 2020-11-23 2023-11-03 北京中航通用科技有限公司 一种数据传输的方法及装置
CN113905350A (zh) * 2021-08-27 2022-01-07 华人运通(上海)自动驾驶科技有限公司 数据上行、下行传输方法、车载智能终端、服务器及系统
CN113905350B (zh) * 2021-08-27 2023-09-15 华人运通(上海)自动驾驶科技有限公司 数据上行、下行传输方法、车载智能终端、服务器及系统

Also Published As

Publication number Publication date
EP3758412B1 (en) 2023-11-15
EP3758412A1 (en) 2020-12-30
EP3758412A4 (en) 2021-06-02
CN110167084B (zh) 2021-07-27
JP7174834B2 (ja) 2022-11-17
US11350318B2 (en) 2022-05-31
CN110167084A (zh) 2019-08-23
US20200413299A1 (en) 2020-12-31
JP2021521749A (ja) 2021-08-26

Similar Documents

Publication Publication Date Title
WO2020034758A1 (zh) 多通道数据传输方法及装置
US20210234798A1 (en) Data transmission method and apparatus, computer readable medium, and electronic device
US11463511B2 (en) Model-based load balancing for network data plane
US10680928B2 (en) Multi-stream transmission method and device in SDN network
CN110022264A (zh) 控制网络拥塞的方法、接入设备和计算机可读存储介质
CN106233775B (zh) 应用程序或无线电信息在网络数据包头中的插入和使用
US20240069977A1 (en) Data transmission method and data transmission server
US11050706B2 (en) Automated autonomous system based DNS steering
CN113285931B (zh) 流媒体的传输方法、流媒体服务器及流媒体系统
CN111769998A (zh) 一种网络时延状态的探测方法及装置
US11064021B2 (en) Method, device and computer program product for managing network system
CN107872471B (zh) 远程桌面图像指令处理方法和系统
JP7050094B2 (ja) パケット送信方法、プロキシサーバ、およびコンピュータ読取り可能記憶媒体
CN114500633B (zh) 数据转发方法、相关装置、程序产品及数据传输系统
WO2022143468A1 (zh) 数据传输方法、装置、系统及存储介质
US8995269B2 (en) Computer readable storage medium storing congestion control program, information processing apparatus, and congestion control method
WO2023213089A1 (zh) 数据处理方法、装置、计算机可读介质及终端设备
US20190342227A1 (en) Load Sharing Method and Network Device
WO2018019018A1 (zh) 一种分发策略生成方法、装置及网络优化系统
WO2023213086A1 (zh) 数据处理方法、装置、计算机可读介质及电子设备
WO2024001451A1 (zh) 业务数据包的处理方法、装置、介质及电子设备
WO2023193432A1 (zh) 一种数据转发方法及相关设备
Ran et al. Agile: A high-scalable and low-jitter flow tables lifecycle management framework for multi-core programmable data plane
WO2024082882A1 (zh) 多媒体内容的传输方法、装置、设备及存储介质
WO2023202241A1 (zh) 一种通信方法及相关产品

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: 19850324

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019850324

Country of ref document: EP

Effective date: 20200922

ENP Entry into the national phase

Ref document number: 2021510518

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE