CN113489786A - Long connection network weak network reconnection method and retransmission method - Google Patents
Long connection network weak network reconnection method and retransmission method Download PDFInfo
- Publication number
- CN113489786A CN113489786A CN202110760713.8A CN202110760713A CN113489786A CN 113489786 A CN113489786 A CN 113489786A CN 202110760713 A CN202110760713 A CN 202110760713A CN 113489786 A CN113489786 A CN 113489786A
- Authority
- CN
- China
- Prior art keywords
- request
- request message
- message
- client
- push
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 52
- 230000004044 response Effects 0.000 claims abstract description 85
- 238000012545 processing Methods 0.000 claims abstract description 45
- 230000008859 change Effects 0.000 claims description 14
- 238000010586 diagram Methods 0.000 description 14
- 238000004590 computer program Methods 0.000 description 7
- 230000003993 interaction Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000011161 development Methods 0.000 description 3
- 230000002452 interceptive effect Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000011144 upstream manufacturing Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 239000002131 composite material Substances 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- PCHJSUWPFVWCPO-UHFFFAOYSA-N gold Chemical compound [Au] PCHJSUWPFVWCPO-UHFFFAOYSA-N 0.000 description 2
- 239000010931 gold Substances 0.000 description 2
- 229910052737 gold Inorganic materials 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Abstract
The invention relates to a long connection network weak network reconnection method and a retransmission method, which comprise the following steps: processing the request message according to the sequence of the request identifier corresponding to the request message of the client; when a request identifier corresponding to a received request message of a client is discontinuous with a request identifier corresponding to a previous request message, caching the request message corresponding to the request identifier; and when the request identification corresponding to the request message of the client which is continuously received is continuous with the request identification corresponding to the cached request message, after the current request message is processed, obtaining the cached request message and processing the cached request message. The server sends a push request message to the client and caches the push request message; and when the push response message returned by the client is not received within the first preset time, resending the push response message according to the cached push request message. The scheme of the invention solves the problem of weak network under various scenes of long-connection hand-game projects, and ensures the game experience of users.
Description
Technical Field
The invention relates to the technical field of network communication, in particular to a long connection network weak network reconnection method and a retransmission method.
Background
With the rapid popularization of smart phones and the rapid development of networks, the related services of the mobile internet have gradually become the focus of attention of various domestic manufacturers. From the overall industry, the Chinese mobile game industry is in a fast development stage. In recent years, the mobile game industry in China has been developed rapidly under the combined promotion of telecom operators and mobile game developers. With the development of interactive entertainment technology, various types of interactive game applications have been developed greatly, and there are various game types and game control modes, and the game forms are excessive from computers or game machines to mobile phone games.
The long connection generally means that the same connection is multiplexed when the client and the server communicate data, and both the client and the server can receive and transmit data (bi-directionally), and is generally used in a service scene with stronger interactivity. The traditional PC side has little weak network related processing because the network environment is relatively good. But to the mobile end, the weak network problem is amplified due to the differences in the mobile network environment, such as in subways, elevators. For long-connection hand games, the weak net problem is relatively prominent. Firstly, long connection hand trip is usually real-time interactive stronger, and weak net is great to experience influence, and secondly long connection is two-way communication, and weak net scene is more complicated, so needs a set of relatively perfect solution.
Regarding the weak network, the mobile side App (application) is mostly based on the http request-response model, and the server is stateless. Therefore, when weak networks mostly appear, the client requests are retransmitted or are sequentially processed in a mode of buffering the requests to a queue, namely the requests are mainly processed by the client. For a long-connection hand-trip project, the long-connection hand-trip project not only comprises a request-response model, but also comprises scenes such as server pushing and the like, and the traditional scheme cannot solve the weak network problem of other scenes or mixed scenes. The long-connection hand-trip server is usually stateful, and the client simply retransmits, so that the server performs secondary processing and affects the traffic (the http server is stateless, so that the http server can perform multiple processing-power and the like).
Therefore, a solution for weak network suitable for long-connection hand-game projects is needed to solve the problem of game experience caused by the common weak network state in the prior art.
Disclosure of Invention
The invention provides a long connection network weak network reconnection method and a retransmission method, which solve the problem of game experience caused by a common weak network state in the prior art.
According to one aspect of the invention, a method for reconnecting a weak network of a long connection network is provided, which comprises the following steps:
processing the request message according to the sequence of the request identifier corresponding to the request message of the client;
when the received request identification corresponding to the request message of the client is not continuous with the request identification corresponding to the previous request message, caching the request message corresponding to the request identification; and continuing to receive the request message of the client;
and when the request identification corresponding to the request message of the client which is continuously received is continuous with the request identification corresponding to the cached request message, after the current request message is processed, obtaining and processing the cached request message.
The method further comprises the following steps:
and after the current request message is processed, processing the cached request message and the current request message according to the sequence of the request identifiers when the request identifier corresponding to the cached request message is determined to be continuous with the request identifier corresponding to the currently processed request message.
The method further comprises the following steps:
when the request identifications corresponding to the plurality of request messages are not continuous, after the request messages corresponding to the complete continuous request identifications are received, the corresponding request messages are processed one by one according to the sequence of the request identifications.
The method further comprises the following steps:
when the request identifications corresponding to the received request messages and the request identifications corresponding to the last request message are missing, caching the current request message; and continuing to receive the request messages until all the missing request messages are received, and processing the corresponding request messages one by one according to the sequence of the request identifications.
The method further comprises the following steps:
the server caches a response message corresponding to the client request message after returning the response message according to the request identifier of the client;
and when a request message corresponding to the request identifier of the client is received again, returning to the client according to the cached response message.
The method further comprises the following steps:
when the same service request of the client comprises a plurality of request messages, the request messages included in the service request are processed one by one according to the sequence of the corresponding request identifiers, and the corresponding response messages are cached;
and combining the cached response messages into a combined response message according to the corresponding request identifier, and returning the combined response message to the client.
According to another aspect of the present invention, there is provided a long connection network weak network retransmission method, including:
the server sends a push request message to the client and caches the push request message;
and when the push response message returned by the client is not received within the first preset time, retransmitting the push response message according to the cached push request message.
The method further comprises the following steps:
and when a push response message returned by the server is received, deleting the push request message corresponding to the push response message from the cache.
The method further comprises the following steps:
and detecting the push response message in the cache by taking the second preset time length as a period, and retransmitting the push request message which is cached after exceeding the second preset time length.
The method further comprises the following steps:
the push request message only contains corresponding data change information;
and after receiving the data change information, the client sends a request response message to the server to acquire the specific data change content corresponding to the data change information.
The beneficial effect who adopts above-mentioned scheme is:
processing the request message according to the sequence of the request identifier corresponding to the request message of the client; when the received request identification corresponding to the request message of the client is not continuous with the request identification corresponding to the previous request message, caching the request message corresponding to the request identification; and continuing to receive the request message of the client; and when the request identification corresponding to the request message of the client which is continuously received is continuous with the request identification corresponding to the cached request message, after the current request message is processed, obtaining and processing the cached request message. The server sends a push request message to the client and caches the push request message; and when the push response message returned by the client is not received within the first preset time, retransmitting the push response message according to the cached push request message. In the scheme of the invention, a plurality of schemes of requesting/retransmitting according to the sequence of the request identifier by the client, caching the response message by the server, combining a plurality of response packets of the same request, realizing the caching of the request message by the server and processing according to the sequence of the serial number are adopted, thereby solving the problem of weak network in various scenes of long-connection hand-game projects and ensuring the game experience of users.
Drawings
Fig. 1 is a schematic flowchart of a weak network reconnection method for a long connection network according to an embodiment of the present invention.
Fig. 2 is a schematic flowchart of a retransmission method for a weak network of a long connection network according to an embodiment of the present invention.
Fig. 3 is a schematic diagram of interaction of weak network processing messages for a request response model according to an embodiment of the present invention.
Fig. 4 is a schematic diagram of a weak network processing message interaction for a push model according to an embodiment of the present invention.
Fig. 5 is a schematic diagram of interaction of processing messages by the weak network for a composite scenario according to an embodiment of the present invention.
Detailed Description
The principles and features of this invention are described below in conjunction with the following drawings, which are set forth by way of illustration only and are not intended to limit the scope of the invention. It should be noted that the embodiments and features of the embodiments of the present application may be combined with each other without conflict.
Due to unstable factors (mainly network scenes such as network jitter and time delay) of a mobile phone network environment, an uplink packet sent by a client side or a downlink packet sent by a server side is lost, and if weak network processing is not performed, abnormal performance of the client side may be caused.
The invention defines and realizes three communication models in order to deal with different service scenes of long-connection handgames. Respectively, a Request-Response model, a Notify model and a Push model, which are used in the data interaction phase.
Request-Response (Request-Response model): the client sends a Request (an uplink Request sent by the client to the server) Request, which carries a Request id (a Request identifier id carried in the client Request in a Request-Response mode), and the server must respond by replying a corresponding Response (a downlink Response corresponding to the client Request returned by the server). Otherwise the client will retry.
Notify (notification model): the client can send the data to the server, and the server can send the data to the client without responding to the other side.
Push model (Push model): the Push sent by the server to the client needs the client to send a PushSuccess confirmation message (a confirmation message replied by the client to the server after confirming the Push message is received), otherwise, retry is carried out
For example, a request response model may be used for UI operations that are common in hand games. The role scene moving operation in the hand tour is more suitable for the Notify model. The server player in the hand game regularly returns physical strength and the like, and the Push model is suitable for the server player in the hand game.
The invention is further described below with reference to the accompanying drawings.
As shown in fig. 1, a schematic flow chart of a long connection network weak network reconnection method provided in embodiment 1 of the present invention is specifically as follows:
and step 11, processing the request message according to the sequence of the request identifier corresponding to the request message of the client.
In this embodiment, the server processes the requests according to the order of the request messages sent by the client. The order of the request messages is determined by the request identities (requestids) carried by the request messages. Each time the client sends an uplink packet, the request Id is carried, and the request is pressed into a queue sequence request.
When the request of the client is overtime (uplink packet loss or downlink packet loss), the same request Id request is used for retry, namely if a response packet corresponding to the request1 is not received, the request2 is not tried, and the request1 is retried all the time.
The client's request must be continuous.
In some special scenarios, the client may have a situation that the first 1 request is not received and the next request is to be issued. In this case, the request transmission of the client may no longer be continuous. For example, the client sends request1, but the upstream packet is lost due to the weak network problem, and the client sends request2 in some scenarios without always requesting 1 again.
In this embodiment, after the server processes the request message, the server adds the response message to the cache corresponding to the requestId. The client carries the received maximum response Id to inform the server to delete the corresponding cache. When the client retries with the requestId, the server directly returns the response message corresponding to the cache without repeatedly processing the request.
When the server detects that the requests are not consecutive, the current request is added directly to the request cache instead of being processed directly. And sequentially processing the requests until the correct request id is received. That is, the server side ensures that the processing sequence is processed according to the request sequence number, but not according to the received sequence.
And step 13, when the request identification corresponding to the request message of the client terminal which is continuously received is continuous with the request identification corresponding to the cached request message, after the current request message is processed, obtaining the cached request message and processing the request message.
In this embodiment, the request messages of the client are processed in sequence only when the request identifiers ID of the request messages of the client that are continuously received are consecutive, otherwise, the request messages are only stored in the cache. Meanwhile, when processing the request of the client, the server also pays attention to whether the request identifier corresponding to the currently processed request is continuous with the request identifier in the cache, and if so, the server directly processes the request in the cache after processing the current request.
In this embodiment, after the current request message is processed, when it is determined that the request identifier corresponding to the cached request message is consecutive to the request identifier corresponding to the currently processed request message, the cached request message and the current request message are processed according to the order of the request identifiers.
In this embodiment, when the request identifiers corresponding to the plurality of request messages are not continuous, after receiving the request messages corresponding to the complete continuous request identifiers, the corresponding request messages are processed one by one according to the sequence of the request identifiers.
In this embodiment, when a request identifier corresponding to a received request message and a request identifier corresponding to a previous request message lack a plurality of request identifiers corresponding to request messages, the current request message is cached; and continuing to receive the request messages until all the missing request messages are received, and processing the corresponding request messages one by one according to the sequence of the request identifications.
In this embodiment, after returning a response message corresponding to a client request message according to a request identifier of the client, the server caches the response message;
and when a request message corresponding to the request identifier of the client is received again, returning to the client according to the cached response message.
In this embodiment, when the same service request of the client includes multiple request messages, the request messages included in the service request are processed one by one according to the sequence of the corresponding request identifiers, and the corresponding response messages are cached;
and combining the cached response messages into a combined response message according to the corresponding request identifier, and returning the combined response message to the client.
In the embodiment of the invention, the request message is processed according to the sequence of the request identifier corresponding to the request message of the client; when the received request identification corresponding to the request message of the client is not continuous with the request identification corresponding to the previous request message, caching the request message corresponding to the request identification; and continuing to receive the request message of the client; and when the request identification corresponding to the request message of the client which is continuously received is continuous with the request identification corresponding to the cached request message, after the current request message is processed, obtaining and processing the cached request message. In the scheme of the invention, a plurality of schemes of requesting/retransmitting according to the sequence of the request identifier by the client, caching the response message by the server, combining a plurality of response packets of the same request, realizing the cache of the request message by the server and processing according to the sequence of the serial number are adopted, thereby solving the problem of weak network in the request-response scene of the long-connection hand game project and ensuring the game experience of the user.
As shown in fig. 2, a retransmission method for a weak network in a long connection network is provided in embodiment 2 of the present invention, wherein,
In this embodiment, all push requests of the server carry the push request message pushRequestId, and the push request message is added to the push cache.
And sending a push message to the client, and under a normal condition, if the push message is received by the client, replying PushSuccess to confirm that the push message is received. And after receiving PushSuccess, the server removes the previous push request message from the cache according to the pushRequestId.
And step 22, when the push response message returned by the client is not received within the first preset time, resending the push response message according to the cached push request message.
In this embodiment, if the client does not reply to PushSuccess, it indicates that a weak network may occur and packet loss occurs. That is, if the push response message PushSuccess returned by the client is not received within a set duration, the server resends the push response message according to the push request message in the cache, and waits for the response of the client.
In this embodiment, the server may further start a timer, periodically check the push buffered message according to the configured interval time (the first preset time duration), and attempt to retransmit the message. The expiration time of the push message is configured, and the phenomenon that the push cache is too large is avoided.
In this embodiment, when a push response message returned by the server is received, the push request message corresponding to the push response message is deleted from the cache.
In this embodiment, the push response message in the cache is detected with a second preset duration as a period, and the push request message that is still cached after exceeding the second preset duration is retransmitted.
In this embodiment, the push request message only includes corresponding data change information;
and after receiving the data change information, the client sends a request response message to the server to acquire the specific data change content corresponding to the data change information.
In the scheme of the invention, aiming at the weak network processing of a push model, a server sends a push request message to a client and caches the push request message; and when the push response message returned by the client is not received within the first preset time, retransmitting the push response message according to the cached push request message. After the server pushes the message, if the server cannot receive the reply message within a set time length, a retransmission mechanism is started. Whether the push request message exists in the cache is periodically detected by using a timer to determine whether the push request message needs to be retransmitted, so that the problem of retransmitting the server message is well solved, and the user game experience in a weak network state is guaranteed.
In fact, the embodiment of the present invention designs a specific weak network processing scheme for the Request-Response model, the Notify model, and the Push model, and the specific process is described by the following three specific embodiments.
Fig. 3 is a schematic diagram of interaction of weak network processing messages for a request response model according to an embodiment of the present invention, wherein,
a client:
each time an upstream packet is sent, the request Id is carried, and the request is pushed into a queue sequence request. When the request is overtime (uplink packet loss or downlink packet loss), the same request id is used for retry (i.e. if the response packet corresponding to the request1 is not received, the request2 is not attempted to be sent, and the request1 is always retried). The requests must be continuous.
In some special scenarios, the client may have a situation that the first 1 request is not received and the next request is to be issued. In this case, the request transmission of the client may no longer be continuous. Examples are: the client sends request1, but the upstream packet is lost due to the weak network problem, and the client sends request2 in some scenes without always requesting 1 again.
A server side:
after the server processes the request message, the server adds the response message to the cache corresponding to the requestId. The client carries the received maximum response Id to inform the server to delete the corresponding cache.
When the client retries with the requestId, the server directly returns the response message corresponding to the cache without repeatedly processing the request. Because the mobile game server is connected with the mobile game server for a long time, the memory is in a state and the request can not be consumed repeatedly (the same request is processed for a plurality of times), a response message cache is realized.
When a plurality of service response packets exist for the same request (which generally depends on service scene requirements), the response packets are respectively added into a connection response packet queue after the processing of related services is finished, and after all services are processed, the response packets in the connection response packet queue are sequentially taken out and combined to form a response message to be returned to a client, and meanwhile, the response message is added into a response message cache.
For the above special scenes of the client, when detecting that the requests are not continuous, the current requests are directly added into the request cache instead of being directly processed, and the requests are sequentially processed in sequence until the correct request id is received. That is, the server side ensures that the processing sequence is processed according to the request sequence number, but not according to the received sequence. For example, the server side receives the request2 first, finds that the request sequence number to be processed by the server side is 1, and directly adds the request2 to the request cache at the moment. When request1 is received, it is processed directly. And after the processing is finished, finding the request2 from the request cache for processing, and so on.
Fig. 4 is a schematic diagram of a weak network processing message interaction for a push model according to an embodiment of the present invention, wherein,
server side/client side:
all push requests carry pushRequestIds, and meanwhile, the push request message is added into a push cache.
When the push message is sent to the client, if the push message is received by the client, the client needs to reply PushSuccess to confirm that the push message is received. And after receiving PushSuccess, the server removes the previous push request message from the cache according to the pushRequestId.
If the client does not reply PushSuccess, the weak network is possibly generated, and packet loss occurs. The server side starts a timer, periodically checks the push cache message according to the configured interval time and tries to resend the message (the expiration time of the push message is configured to avoid the push cache from being too large).
Fig. 5 is a schematic diagram of a weak network processing message interaction for a composite scenario according to an embodiment of the present invention, wherein,
in some service scenarios, there may be both request response messages and notification messages. For example, the client initiates request1 and the server process returns a 200 gold message, but the downstream packet is lost. At the same time, the server notifies the client 300 of the gold message. The client resends request1 and the server returns a 200-dollar message that now presents a problem due to the weak network, and the client normally should be 300 dollars, but now appears to be 200 dollars due to the weak network. This is a weak net situation that is relatively common for long-connection handgames.
The notification type message at the server side does not push a data correlation, but pushes a data change message.
And after receiving the pushed data change message, the client requests the corresponding changed data in a request response mode. That is, the request response and the notification message exist simultaneously, and all become a single request response mode.
The notification model in the above three communication models is a notification, i.e. the message in the service scenario is relatively unimportant, so that even if the weak network packet loss problem occurs, the notification model has no practical great influence.
In the embodiment of the invention, the request message is processed according to the sequence of the request identifier corresponding to the request message of the client; when the received request identification corresponding to the request message of the client is not continuous with the request identification corresponding to the previous request message, caching the request message corresponding to the request identification; and continuing to receive the request message of the client; and when the request identification corresponding to the request message of the client which is continuously received is continuous with the request identification corresponding to the cached request message, after the current request message is processed, obtaining and processing the cached request message. The server sends a push request message to the client and caches the push request message; and when the push response message returned by the client is not received within the first preset time, retransmitting the push response message according to the cached push request message. In the scheme of the invention, a plurality of schemes of requesting/retransmitting according to the sequence of the request identifier by the client, caching the response message by the server, combining a plurality of response packets of the same request, realizing the caching of the request message by the server and processing according to the sequence of the serial number are adopted, thereby solving the problem of weak network in various scenes of long-connection hand-game projects and ensuring the game experience of users.
The present invention has been described in detail with reference to specific embodiments, but the above embodiments are merely illustrative, and the present invention is not limited to the above embodiments.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.
Claims (10)
1. A method for reconnecting a weak network of a long connection network is characterized in that the method comprises the following steps:
processing the request message according to the sequence of the request identifier corresponding to the request message of the client;
when the received request identification corresponding to the request message of the client is not continuous with the request identification corresponding to the previous request message, caching the request message corresponding to the request identification; and continuing to receive the request message of the client;
and when the request identification corresponding to the request message of the client which is continuously received is continuous with the request identification corresponding to the cached request message, after the current request message is processed, obtaining and processing the cached request message.
2. The method of claim 1, wherein the method further comprises:
and after the current request message is processed, processing the cached request message and the current request message according to the sequence of the request identifiers when the request identifier corresponding to the cached request message is determined to be continuous with the request identifier corresponding to the currently processed request message.
3. The method of claim 1, wherein the method further comprises:
when the request identifications corresponding to the plurality of request messages are not continuous, after the request messages corresponding to the complete continuous request identifications are received, the corresponding request messages are processed one by one according to the sequence of the request identifications.
4. The method of claim 1, wherein the method further comprises:
when the request identifications corresponding to the received request messages and the request identifications corresponding to the last request message are missing, caching the current request message; and continuing to receive the request messages until all the missing request messages are received, and processing the corresponding request messages one by one according to the sequence of the request identifications.
5. The method of claim 1, wherein the method further comprises:
the server caches a response message corresponding to the client request message after returning the response message according to the request identifier of the client;
and when a request message corresponding to the request identifier of the client is received again, returning to the client according to the cached response message.
6. The method of claim 1, wherein the method further comprises:
when the same service request of the client comprises a plurality of request messages, the request messages included in the service request are processed one by one according to the sequence of the corresponding request identifiers, and the corresponding response messages are cached;
and combining the cached response messages into a combined response message according to the corresponding request identifier, and returning the combined response message to the client.
7. A long connection network weak network retransmission method is characterized by comprising the following steps:
the server sends a push request message to the client and caches the push request message;
and when the push response message returned by the client is not received within the first preset time, retransmitting the push response message according to the cached push request message.
8. The method of claim 7, wherein the method further comprises:
and when a push response message returned by the server is received, deleting the push request message corresponding to the push response message from the cache.
9. The method of claim 8, wherein the method further comprises:
and detecting the push response message in the cache by taking the second preset time length as a period, and retransmitting the push request message which is cached after exceeding the second preset time length.
10. The method of claim 7, wherein the method further comprises:
the push request message only contains corresponding data change information;
and after receiving the data change information, the client sends a request response message to the server to acquire the specific data change content corresponding to the data change information.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110760713.8A CN113489786B (en) | 2021-07-01 | 2021-07-01 | Reconnection method and retransmission method for weak network of long connection network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110760713.8A CN113489786B (en) | 2021-07-01 | 2021-07-01 | Reconnection method and retransmission method for weak network of long connection network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113489786A true CN113489786A (en) | 2021-10-08 |
| CN113489786B CN113489786B (en) | 2023-11-14 |
Family
ID=77941125
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110760713.8A Active CN113489786B (en) | 2021-07-01 | 2021-07-01 | Reconnection method and retransmission method for weak network of long connection network |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113489786B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114146417A (en) * | 2021-12-03 | 2022-03-08 | 广州银汉科技有限公司 | Game weak network test analysis platform |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104023020A (en) * | 2014-06-13 | 2014-09-03 | 中国民航信息网络股份有限公司 | TypeB message subscription and push system for mobile equipment and corresponding method |
| CN106714334A (en) * | 2016-12-22 | 2017-05-24 | 网易（杭州）网络有限公司 | Disconnection reconnection method, device and system |
| CN108989179A (en) * | 2017-05-31 | 2018-12-11 | 腾讯科技（深圳）有限公司 | Message treatment method and device, storage medium |
| CN109286665A (en) * | 2018-09-17 | 2019-01-29 | 北京龙拳风暴科技有限公司 | The real-time long link processing method and processing device of moving game |
| CN109587235A (en) * | 2018-11-30 | 2019-04-05 | 深圳市网心科技有限公司 | A kind of data access method based on network library, client, system and medium |
| CN110008037A (en) * | 2019-02-28 | 2019-07-12 | 北京达佳互联信息技术有限公司 | Message treatment method, device and storage medium |
| CN112040501A (en) * | 2020-08-28 | 2020-12-04 | 康键信息技术（深圳）有限公司 | Detection and early warning method, device, equipment and storage medium for mobile network quality |
| CN112169312A (en) * | 2020-09-27 | 2021-01-05 | 厦门雅基软件有限公司 | Queuing scheduling method, device, equipment and storage medium for cloud game service |
| CN112333083A (en) * | 2020-10-30 | 2021-02-05 | 平安付科技服务有限公司 | Transaction information processing method and device, computer equipment and computer readable medium |
-
2021
- 2021-07-01 CN CN202110760713.8A patent/CN113489786B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104023020A (en) * | 2014-06-13 | 2014-09-03 | 中国民航信息网络股份有限公司 | TypeB message subscription and push system for mobile equipment and corresponding method |
| CN106714334A (en) * | 2016-12-22 | 2017-05-24 | 网易（杭州）网络有限公司 | Disconnection reconnection method, device and system |
| CN108989179A (en) * | 2017-05-31 | 2018-12-11 | 腾讯科技（深圳）有限公司 | Message treatment method and device, storage medium |
| CN109286665A (en) * | 2018-09-17 | 2019-01-29 | 北京龙拳风暴科技有限公司 | The real-time long link processing method and processing device of moving game |
| CN109587235A (en) * | 2018-11-30 | 2019-04-05 | 深圳市网心科技有限公司 | A kind of data access method based on network library, client, system and medium |
| CN110008037A (en) * | 2019-02-28 | 2019-07-12 | 北京达佳互联信息技术有限公司 | Message treatment method, device and storage medium |
| CN112040501A (en) * | 2020-08-28 | 2020-12-04 | 康键信息技术（深圳）有限公司 | Detection and early warning method, device, equipment and storage medium for mobile network quality |
| CN112169312A (en) * | 2020-09-27 | 2021-01-05 | 厦门雅基软件有限公司 | Queuing scheduling method, device, equipment and storage medium for cloud game service |
| CN112333083A (en) * | 2020-10-30 | 2021-02-05 | 平安付科技服务有限公司 | Transaction information processing method and device, computer equipment and computer readable medium |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114146417A (en) * | 2021-12-03 | 2022-03-08 | 广州银汉科技有限公司 | Game weak network test analysis platform |
| CN114146417B (en) * | 2021-12-03 | 2023-09-08 | 广州银汉科技有限公司 | Game weak network test analysis platform |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113489786B (en) | 2023-11-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2436245C2 (en) | System and method for implementing mbms handover during downloaded delivery | |
| US20070070988A1 (en) | Method For Transmitting Deferred Messages | |
| US7433344B2 (en) | Mobile communication system and method for providing real time messenger service among mobile communication terminals | |
| KR100690242B1 (en) | Mobile terminal and method for transmitting image during use of mobile messenger service | |
| EP1850545A1 (en) | Voice messaging method and mobile terminal supporting voice messaging in mobile messenger service | |
| CN103152650A (en) | Robust file casting for mobile TV | |
| CN107567107B (en) | Data transmission method and device | |
| JP2007133869A (en) | Terminal machine and its message processing method | |
| US9571409B2 (en) | Maximum transmission unit negotiation method and data terminal | |
| CN101814971A (en) | Method for transmitting mobile phone file | |
| EP2571296B1 (en) | Method, device and mobile multi-media broadcasting service system for transmitting data information | |
| US8095116B2 (en) | Method for delivering multimedia files | |
| US8341272B2 (en) | Method for improving a TCP data transmission in case the physical transmission medium is disconnected | |
| RU2449474C1 (en) | Method of protecting readdressing messages from duplication during multimedia message interaction and multimedia message gateway | |
| CN111917562B (en) | Broadcast message forwarding method, device, equipment and storage medium | |
| CN112787945B (en) | Data transmission method, data transmission device, computer readable medium and electronic equipment | |
| CN101977358A (en) | Method, device and equipment for transmitting data short messages | |
| CN103684707A (en) | Server-side and user-side message transmission processing method, message transmission method and message transmission system | |
| CN111541555A (en) | Group chat optimization method and related product | |
| US8520521B2 (en) | Method and apparatus for initiating a storage window in a wireless communications system | |
| CN113489786B (en) | Reconnection method and retransmission method for weak network of long connection network | |
| JP2003008642A (en) | Multi-cast communication method and system | |
| CN108718274A (en) | A kind of anti-loss method of instant communication information | |
| US8744499B2 (en) | Mobile terminal and multimedia messaging service notification message processing method | |
| CN103841141A (en) | Multimedia communication system and method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |