CN112689018A - Quick message pushing method - Google Patents

Quick message pushing method Download PDF

Info

Publication number
CN112689018A
CN112689018A CN202011587924.8A CN202011587924A CN112689018A CN 112689018 A CN112689018 A CN 112689018A CN 202011587924 A CN202011587924 A CN 202011587924A CN 112689018 A CN112689018 A CN 112689018A
Authority
CN
China
Prior art keywords
data
message
client
server
transmission
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
Application number
CN202011587924.8A
Other languages
Chinese (zh)
Other versions
CN112689018B (en
Inventor
彭恩江
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Chinaccs Information Industry Co ltd
Original Assignee
Chinaccs Information Industry Co ltd
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 Chinaccs Information Industry Co ltd filed Critical Chinaccs Information Industry Co ltd
Priority to CN202011587924.8A priority Critical patent/CN112689018B/en
Publication of CN112689018A publication Critical patent/CN112689018A/en
Application granted granted Critical
Publication of CN112689018B publication Critical patent/CN112689018B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

The invention discloses a method for quickly pushing messages, which relates to the technical field of information, and adopts the technical scheme that the method comprises the steps of acquiring the transmission size of a network data frame as a transmission standard quantity; packing necessary data by a transmission standard quantity, and sending the packed data to a client; and the server side inquires the necessary data of the message from the database again to obtain more necessary data, stores the necessary data in the cache server for waiting for next sending, and repeats the steps until the sending of the secondary data is finished by taking the secondary data of the message as a sending object after the sending of the necessary data of the message is finished. The invention has the beneficial effects that: the data volume transmitted each time is transmitted in a data frame in the form of data packets, so that the efficiency can reach the highest. The client does not need to wait for the completion of the transmission of the plurality of data packets and then carry out analysis operation. The impact of network delay can be reduced.

Description

Quick message pushing method
Technical Field
The invention relates to the technical field of information, in particular to a method for quickly pushing a message.
Background
In some scenarios in the security field, event information of the number of the event venue (phone number or other unique device number) needs to be displayed on a special terminal (software on a PC) of the dispatch center for dispatch personnel to assign. Or the event information is displayed on a terminal of the event handling mechanism and is read by the event handling personnel. The display information comprises information acquired from a database and a third-party platform besides the number and the position.
When the message is pushed to the client, generally only necessary numbers are pushed to the client, and the client inquires additional necessary information from the server according to the actual situation.
Because the information display is based on the query request actively initiated by the client, the server further processes according to the query request. After the server end completes the response, the client end can display the alarm information. Where there may be 1 or more network requests. There are 3-way handshakes for HTTP requests based on the TCP/IP protocol. Therefore, the display delay of the entire alarm information is relatively large (about 500ms or more).
In the real-time message pushing process, the server generally functions as the message delivery and the response client requests for additional messages, so the general situation is divided into two types:
firstly, after receiving the message, the server forwards the message to the client, the client initiates the request again according to the actual situation, and the server returns the result of the query response according to the request to the client, as shown in the figure 1 of the specification.
Secondly, after receiving the message, the server side prepares to push the additional information required by the client side to the client side at one time, as shown in the attached figure 2 of the specification.
The prior art has the defects that after receiving a message from an original message source, a server or a client can display a popup screen at the client only after waiting for a result returned by a database or a third-party service, and the display has a large delay, so that the effect is extremely poor in some scenes with high requirements on delay.
In the message transmission process, data transmitted between the client and the server is generally in a form based on a service logic data packet (that is, even if data is transmitted in a TCP stream manner, data is obviously transmitted in a form of a logic data packet), and when the data packet is not completely transmitted, the client cannot process the data packet and needs to wait for the completion of the transmission of the current data packet.
Referring to fig. 1 and 2 of the above specification, the call duration of the database and the third party service in the sequence diagram is consistent.
In the first technical scheme, multiple requests relate to the problem of data packet back-and-forth transmission, and even if a long connection form of TCP is used to avoid the 3-way handshake overhead of the TCP protocol, a part of time overhead is still occupied by the transmission of a client request data packet and a server response data packet. In the matching diagram of the first technical solution, the transmission times are 5 times. Assuming a 50ms per transmission delay, the total transmission delay is 250 ms. Considering that if the request packet is too small, the delay transmission algorithm delays 100ms each time, and considering that the client processes the packet 100ms each time, the total delay is 5 × 50ms +2 × 100ms +100ms × 3 — 750 ms. If one considers waiting for the database and third party services (assuming each takes 2000ms to process the respective traffic), the total delay would exceed 4750 ms.
And in the second technical scheme, data transmission is carried out only once, and assuming that each transmission is delayed by 50ms, data packet analysis is carried out only once, and the delay is 100 ms. Waiting for the database and third party services (assuming each took 2000ms to process its own traffic as above), the total delay would exceed 4150 ms.
According to the two technical schemes, the total delay exceeds 4000 ms. The application system, such as a police system, cannot meet the use requirement on occasions with higher requirements on time delay.
Disclosure of Invention
In view of the above technical problems, an object of the present invention is to improve the message display speed by changing the message push processing flow to avoid the network delays and the multiple query delays of the server, and therefore, the present invention provides a method for quickly pushing a message.
The technical scheme is that S1, a client and a server use a TCP/IP protocol for long connection, and after the client and the server are connected, a connection state is maintained and detected through heartbeat; server software dynamically configures TCP sending delay;
s2, carrying out transmission test on the client and the server to obtain the transmission size of the network data frame as a transmission standard quantity;
s3, when receiving the message pushing task, the server firstly inquires the necessary data in the message to be pushed with the database for the first time, the inquiry sequence is carried out according to the priority of the necessary data, and the inquired result is stored in the cache server;
s4, when the server needs to push the message to the client, the server extracts necessary data required by the client from the cache server, packages the necessary data according to the transmission standard quantity measured in S2, and sends the packaged data to the client, namely the packaged data quantity corresponds to the size of the network data frame obtained in the step S2;
s5, synchronizing with S4, the server side inquires the necessary data of the message from the database again, acquires more necessary data and stores the data in the cache server;
s6, after receiving the data sent by S3, the client outputs the necessary data in the acquired message, because the data comprises a plurality of items of necessary information to form a data packet, the client can directly process the data packet and acquire the complete information;
and S7, repeating the steps S4 to S6 until the necessary data transmission of the message is completed, and then repeating the steps S4 to S6 with the secondary data of the message as a transmission object until the secondary data transmission is completed.
Preferably, in S2, specifically,
s21, the client side is connected with the server side;
s22, delaying 3-5 heartbeat cycles, and waiting for connection to be stable;
s23, the client and the server negotiate to perform a network data frame size transmission test;
and S24, obtaining the transmission size of the network data frame as the transmission standard quantity through the test of S23.
The transmission test aims at finding out how large data frames are transmitted most efficiently in the network environment where the client is located.
Preferably, the first query of the necessary data in S3 includes a message number, a phone number, a name, longitude and latitude, and other information;
the re-inquiry of the necessary data in S5 includes, but is not limited to, the number basic information, longitude and latitude, and the like of the same group.
Preferably, in S4, specifically,
s41, the server side judges the total size of the data volume of the necessary data required by the client side;
s42, when the data volume of all the necessary data required by the client after packaging is less than or equal to the transmission standard volume obtained in the S2, packaging all the necessary data and then sending the packaged data to the client to finish the transmission;
s43, when the data volume of all necessary data required by the client is larger than the transmission standard volume obtained in the S2, the necessary data are packed according to the priority of the necessary data and then the next step is carried out;
the data volume of the packed data packet is less than or equal to the transmission standard volume obtained in the step S2;
s44, the server side sends the necessary data packaged in S43 to the client side to complete the transmission;
and S45, repeating the steps S43 to S45 until all necessary data required by the client are sent.
Preferably, in S44, the server determines the size of the data packet packaged in S43, and if the capacity of the data packet is lower than a set value, the server closes the TCP sending delay function, and then sends the packaged data packet to the client.
Preferably, in S6, specifically,
s61, the client side pre-constructs a complete message frame of the message according to the message;
s62, the client displays the received content in the message box of S61, and the content which is not received yet is displayed in a placeholder form;
s63, the client updates the content in the S63 message box according to the subsequently received message data, and replaces the placeholder with the effective information.
Preferably, in S7, the secondary data of the message includes supplementary data homologous to the necessary message and also includes additional third party data.
Preferably, said S5 further includes,
and synchronously with the step S4, the service end calls a service interface of a third party for preparing the calling of the third party data in the secondary data.
The technical scheme provided by the embodiment of the invention has the following beneficial effects: the data volume transmitted each time is transmitted in a data frame in the form of data packets, so that the efficiency can reach the highest. The client does not need to wait for the completion of the transmission of the plurality of data packets and then carry out analysis operation. The impact of network delay can be reduced. According to the scheme, the processing flow of message pushing is changed to avoid network delay and multiple inquiry delay of the server side so as to improve the message display speed.
Drawings
Fig. 1 is a first sequence diagram of a message push UML in the prior art.
Fig. 2 is a diagram of a message push UML sequence diagram of the prior art.
FIG. 3 is a flow chart of an embodiment of the present invention.
Fig. 4 is a UML sequence diagram according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. Of course, the specific embodiments described herein are merely illustrative of the invention and are not intended to be limiting.
It should be noted that the embodiments and features of the embodiments of the present invention may be combined with each other without conflict.
In the description of the present invention, it is to be understood that the terms "central," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," and the like are used in the orientation or positional relationship indicated in the drawings, which are merely for convenience in describing the invention and to simplify the description, and are not intended to indicate or imply that the referenced device or element must have a particular orientation, be constructed and operated in a particular orientation, and are therefore not to be construed as limiting the invention. Furthermore, the terms "first", "second", etc. are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first," "second," etc. may explicitly or implicitly include one or more of that feature. In the description of the invention, the meaning of "a plurality" is two or more unless otherwise specified.
In the description of the invention, it is to be noted that, unless otherwise explicitly specified or limited, the terms "mounted", "connected" and "disposed" are to be construed broadly, e.g. as being fixedly connected, detachably connected, or integrally connected; can be mechanically or electrically connected; they may be connected directly or indirectly through intervening media, or they may be interconnected between two elements. The specific meaning of the above terms in the creation of the present invention can be understood by those of ordinary skill in the art through specific situations.
Example 1
Referring to fig. 3 and fig. 4, the present invention provides a method for quickly pushing a message, where the precondition configuration conditions are as follows: the client and the server use a TCP/IP protocol for long connection, and after the client and the server are connected, the connection state is maintained and detected through heartbeat.
Server software has capability of dynamically configuring TCP sending delay
The first step is as follows: after the client is normally connected and logs in the message server, and after the connection is stable (for example, after 3-5 heartbeat cycles are delayed), the client and the server negotiate to perform a network data frame size transmission test. The transmission test aims at finding out how large data frames are transmitted most efficiently in the network environment where the client is located.
The second step is that: after receiving the alarm message, the server packs necessary data of the client, such as message number, telephone number, name, longitude and latitude and other information, into a close (internet IP data frame) (first step test result) and sends the close (internet IP data frame) to the client (when the data size exceeds the data size in the first step, other information is not sent, and at the moment, the server closes the TCP sending delay function to send data). At this time, the server side completes one data query of the alarm number, and the query result needs to be stored in the cache server for further processing. Meanwhile, the server side starts a new transaction I, inquires more necessary data and stores the data in the cache server. (the necessary data includes, but is not limited to, basic information of numbers of the same group, longitude and latitude, etc.; additional third party data). Meanwhile, the server also opens a new transaction two and calls a third-party service interface for processing additional service logic.
Second step-client: and after receiving the data sent by the server side in the second step, the client side immediately processes the data and pops up a message box, important contents in the message box are attached to the data packet transmitted for the first time and can be directly displayed, and contents not attached to the message box are displayed in a placeholder mode.
The third step: and if the second step does not finish sending all the information, the server side immediately continues to send a second data frame (the data size is close to the data size in the first step), which comprises the message number and the residual unsent data. (these data are individually grouped into a service logic data packet) (if the data are not transmitted, the third operation is repeated)
Third step-client: after the client receives the message sent by the server in the third step, the client updates the appointed message frame or interface according to the message number, and replaces the placeholder with effective information
The fourth step: and obtaining information to be further sent from the cache server, and packaging and sending the service logic data packet according to the data size in the first step. (if the data is not transmitted, the fourth operation is repeated)
The fourth step-client: after the client receives the message sent by the server in the third step, the client updates the appointed message frame or interface according to the message number, and replaces the placeholder with effective information
The fifth step: after receiving the data returned by the third-party service interface and other asynchronously executed task results, the server end packs the data into a service logic data packet with the size close to that of the data in the first step and sends the service logic data packet to the client end (if the data is not sent completely, the fifth step is repeated)
The fifth step-the client: in the same step as the fourth step, the client updates the appointed message frame or interface according to the message number by the received data, and replaces the placeholder with the effective information
The key points of the scheme are as follows:
1, detecting the single data length with highest data transmission efficiency between a server and a client
2, each time data is sent, the maximum length does not exceed the data length obtained by the characteristic 1
And 3, if the length of the transmitted data is too small (less than half of 1500), the service end closes the TCP transmission delay function once. Let the data packet send out quickly
4, the data flow is always from the server side to the client side: the client and the server need to be matched with each other, the server actively pushes data required by the client to the client in sequence, and the client receives the data and displays the data according to business logic.
According to fig. 4, after the client pops the screen for the first time and pushes the message, according to the analysis of the prior art, the transmission is delayed by 50 ms. The server temporarily shuts down the TCP delay algorithm without algorithmic delay. Client processing delays 100 ms. The first screen shot is delayed by 150 ms. Is 4000ms faster than the prior art solutions.
Secondly, the steps of the server processing the database and the third party service are performed simultaneously, and the delay can be considered to be 2000ms in total according to the above technical scheme. The second transmission delay is therefore approximately 2000ms +50ms 2+100ms 2 to 2300 ms.
Even so, the client displays full information from flicking the screen, using 2450ms in total. Is far smaller than the two prior technical schemes.
In addition, in the technical scheme, the data volume transmitted each time is transmitted in one IP data packet, so the efficiency can reach the highest. The client does not need to wait for the completion of the transmission of the plurality of data packets and then carry out analysis operation. The impact of network delay can be reduced.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like that fall within the spirit and principle of the present invention are intended to be included therein.

Claims (8)

1. A method for quickly pushing a message is characterized by comprising the following steps,
s1, the client and the server use TCP/IP protocol to carry out long connection, and after the client and the server are connected, the connection state is maintained and detected through heartbeat; the server dynamically configures the TCP sending delay;
s2, carrying out transmission test on the client and the server to obtain the transmission size of the network data frame as a transmission standard quantity;
s3, when receiving the message pushing task, the server firstly inquires the necessary data in the message to be pushed with the database for the first time, the inquiry sequence is carried out according to the priority of the necessary data, and the inquired result is stored in the cache server;
s4, when the server needs to push the message to the client, the server extracts necessary data required by the client from the cache server, packs the necessary data according to the transmission standard quantity measured in S2, and sends the packed data to the client;
s5, synchronizing with S4, the server side inquires the necessary data of the message from the database again, acquires more necessary data and stores the data in the cache server;
s6, after receiving the data sent by S3, the client outputs the necessary data in the acquired message;
and S7, repeating the steps S4 to S6 until the necessary data transmission of the message is completed, and then repeating the steps S4 to S6 with the secondary data of the message as a transmission object until the secondary data transmission is completed.
2. The method for fast pushing a message according to claim 1, wherein the S2 is specifically,
s21, the client side is connected with the server side;
s22, delaying 3-5 heartbeat cycles, and waiting for connection to be stable;
s23, the client and the server negotiate to perform a network data frame size transmission test;
and S24, obtaining the transmission size of the network data frame as the transmission standard quantity through the test of S23.
3. The method for fast pushing a message according to claim 2, wherein the S4 is specifically,
s41, the server side judges the total size of the data volume of the necessary data required by the client side;
s42, when the data volume of all the necessary data required by the client after packaging is less than or equal to the transmission standard volume obtained in the S2, packaging all the necessary data and then sending the packaged data to the client to finish the transmission;
s43, when the data volume of all necessary data required by the client is larger than the transmission standard volume obtained in the S2, the data are packed according to the priority of the necessary data, and then the next step is carried out;
the data volume of the packed data packet is less than or equal to the transmission standard volume obtained in the step S2;
s44, the server side sends the necessary data packaged in S43 to the client side to complete the transmission;
and S45, repeating the steps S43 to S45 until all necessary data required by the client are sent.
4. The method for fast pushing a message according to claim 3, wherein in S44, the server determines the size of the S43 packaged packet, and if the packet size is lower than a set value, the server turns off the TCP sending delay function, and then sends the packaged packet to the client.
5. The method according to claim 3, wherein the S6 is specifically a message push method,
s61, the client side pre-constructs a complete message frame of the message according to the message;
s62, the client displays the received content in the message box of S61, and the content which is not received yet is displayed in a placeholder form;
s63, the client updates the content in the S63 message box according to the subsequently received message data, and replaces the placeholder with the effective information.
6. The method according to claim 5, wherein in said S7, the secondary data of the message includes supplementary data homologous to the necessary message, and further includes additional third party data.
7. The message fast pushing method according to claim 6, wherein said S5 further comprises,
and synchronously with the step S4, the service end calls a service interface of a third party for preparing the calling of the third party data in the secondary data.
8. The method for quickly pushing the message according to claim 2, wherein the first query of the necessary data in S3 includes message number, phone number, name, longitude and latitude and other information;
the re-inquiry of the necessary data in the step S5 is performed for the first time, and the basic information of the number, the latitude and the longitude of the same group are included.
CN202011587924.8A 2020-12-29 2020-12-29 Quick message pushing method Active CN112689018B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011587924.8A CN112689018B (en) 2020-12-29 2020-12-29 Quick message pushing method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011587924.8A CN112689018B (en) 2020-12-29 2020-12-29 Quick message pushing method

Publications (2)

Publication Number Publication Date
CN112689018A true CN112689018A (en) 2021-04-20
CN112689018B CN112689018B (en) 2023-03-10

Family

ID=75453677

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011587924.8A Active CN112689018B (en) 2020-12-29 2020-12-29 Quick message pushing method

Country Status (1)

Country Link
CN (1) CN112689018B (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140344411A1 (en) * 2013-05-15 2014-11-20 Piazza Technologies, Inc. Method for delivering long polling push messages in a multi-server environment
US20160006817A1 (en) * 2014-07-03 2016-01-07 Telefonaktiebolaget L M Ericsson (Publ) System and method for pushing live media content in an adaptive streaming environment
CN110300050A (en) * 2019-05-23 2019-10-01 中国平安人寿保险股份有限公司 Information push method, device, computer equipment and storage medium
CN111245709A (en) * 2020-02-10 2020-06-05 北京字节跳动网络技术有限公司 Message pushing method and device, electronic equipment and storage medium
CN111818131A (en) * 2020-06-17 2020-10-23 天津异乡好居网络科技有限公司 Message pushing and scheduling system and method
CN112100556A (en) * 2020-08-25 2020-12-18 福建天泉教育科技有限公司 Method and system for optimizing message pushing mode

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140344411A1 (en) * 2013-05-15 2014-11-20 Piazza Technologies, Inc. Method for delivering long polling push messages in a multi-server environment
US20160006817A1 (en) * 2014-07-03 2016-01-07 Telefonaktiebolaget L M Ericsson (Publ) System and method for pushing live media content in an adaptive streaming environment
CN110300050A (en) * 2019-05-23 2019-10-01 中国平安人寿保险股份有限公司 Information push method, device, computer equipment and storage medium
CN111245709A (en) * 2020-02-10 2020-06-05 北京字节跳动网络技术有限公司 Message pushing method and device, electronic equipment and storage medium
CN111818131A (en) * 2020-06-17 2020-10-23 天津异乡好居网络科技有限公司 Message pushing and scheduling system and method
CN112100556A (en) * 2020-08-25 2020-12-18 福建天泉教育科技有限公司 Method and system for optimizing message pushing mode

Also Published As

Publication number Publication date
CN112689018B (en) 2023-03-10

Similar Documents

Publication Publication Date Title
US8295820B2 (en) Advanced internet-based caller ID information/data for mobile phones and mobile networks
EP1625512B1 (en) Peer-to-peer dynamic web page sharing
EP1192780B1 (en) Apparatus and method for internet advertising
US6687743B1 (en) Client server communications for a mobile computing device
US8103253B2 (en) System and method for transmitting messages to a wireless communication device
CN103457843A (en) Communication method, communication system, relay gateway device, application server and client side
CN109688196A (en) Method for pushing, device, electronic equipment and the readable storage medium storing program for executing of order status
EP2740250B1 (en) Method and apparatus for high performance low latency real time notification delivery
CN107196848B (en) Information push method and device
US9986393B2 (en) System and method of creating and providing SMS HTTP tagging
EP3308506B1 (en) Multimedia messaging service gateway (mmsgw) system, method of operating a multimedia messaging service gateway (mmsgw)system and a software product
CN112689018B (en) Quick message pushing method
KR20140054077A (en) Sending messages from a computing device
US20040230682A1 (en) Handling queued sessions
CN104301352B (en) The adaptation method and device of double-terminal
KR100549684B1 (en) Service System and Method for Displaying Image by Calling Party and Communication Terminal
CN112866622B (en) Information processing method, device, server, storage medium and system
CN111935316B (en) Method and device for acquiring front-end equipment catalog
NO327367B1 (en) Assigning wireless channels in a base station processor
US20090063705A1 (en) System and method of sending compressed html messages over telephony protocol
CN113596002B (en) Service providing method and device
KR20040000203A (en) Contents conversion method for terminal dependent messaging service on wireless internet
JP2005236344A (en) Voip gateway apparatus and positional information transmission method
EP2521036A1 (en) A method, a system, a first server, a second server, a computer program and a computer program product for sending information about users assigned to work on tasks in a computer network
CN113222198A (en) Reservation method and device

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