CN114205167A - Application layer registration keep-alive method, system, electronic equipment and storage medium - Google Patents
Application layer registration keep-alive method, system, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN114205167A CN114205167A CN202111556592.1A CN202111556592A CN114205167A CN 114205167 A CN114205167 A CN 114205167A CN 202111556592 A CN202111556592 A CN 202111556592A CN 114205167 A CN114205167 A CN 114205167A
- Authority
- CN
- China
- Prior art keywords
- message
- user
- custom
- class
- application layer
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 49
- 238000012545 processing Methods 0.000 claims abstract description 95
- 238000004891 communication Methods 0.000 claims abstract description 35
- 230000005540 biological transmission Effects 0.000 claims abstract description 14
- 230000008569 process Effects 0.000 claims description 21
- 230000004044 response Effects 0.000 claims description 20
- 238000004590 computer program Methods 0.000 claims description 5
- 238000007639 printing Methods 0.000 claims description 3
- 238000004064 recycling Methods 0.000 claims description 2
- 230000007246 mechanism Effects 0.000 abstract description 7
- 238000010586 diagram Methods 0.000 description 6
- 238000011161 development Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001681 protective effect Effects 0.000 description 1
- 230000007115 recruitment Effects 0.000 description 1
- 238000012549 training Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/168—Implementing security features at a particular protocol layer above the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/03—Protocol definition or specification
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention provides an application layer registration keep-alive method, a system, electronic equipment and a storage medium, wherein the method comprises the following steps: receiving a message from a network, and sending the message to a client through an I/O thread transmission module; analyzing and coding the message through a system processing class, and sending the self-defined message body to a self-defined processing class after the wss message body is stripped; the user-defined processing class performs read/write timeout check and heartbeat timeout processing on a user-defined message body; and sending the processed custom message body to a message annular queue, forwarding the message annular queue to a message classification processing module, and performing classification processing according to the type of the custom message body. The invention adopts the bottom communication protocol and the self-defined application layer protocol, ensures that the communication between the client and the server is in an online state, and other APPs do not occupy server resources for a long time after accessing the bottom protocol due to the absence of the correct self-defined format protocol and the refresh mechanism, thereby saving the server resources.
Description
Technical Field
The invention relates to the field of application service platforms or cloud services, in particular to an application layer registration keep-alive method, an application layer registration keep-alive system, electronic equipment and a storage medium.
Background
With the rapid development of internet technology, a plurality of application software or service software of individuals or companies appears on the network. Such as english training, chat making friends, recruitment, games, etc. Many of these APPs require interaction with the server background to be used.
The development difficulty of the background of the application server is slightly more complicated than that of the front-end APP, but with the growing demand of the APP, a plurality of open-source server backgrounds such as freeswitch (for the voip protocol) have emerged at present. Janus WebRTC server (web), Netty (custom protocols such as TCP/IP), tomcat (http), etc. The advent of these server platforms has provided a facility for small development teams to launch services.
In the interactive service scenario, the app or the client needs to utilize a registration keep-alive mechanism to the application layer. The purpose of user registration is to inform the server of the user identity, and the server can obtain the communication address of the user. The communication address is used by subsequent communication interactions to communicate with the app. In the process, the user needs to refresh the login state of the user regularly to ensure that the user is always in an online communication state at the server.
Take VOIP background freeswitch as an example, it uses SIP protocol, based on UDP or TCP. Registration and keep-alive of a user is accomplished through the SIP protocol, which specifies the mechanism of the registration message, including the message format and rules of registration refresh. This is a relatively complex mechanism for registration and keep-alive using the SIP protocol for a typical general development team who does not need to communicate with other vendors from many parties.
Disclosure of Invention
In view of the above problems, the present invention provides an application layer registration keep-alive method, system, electronic device and storage medium, which can be adapted to a customized communication system application service, so that a user can quickly develop a stable application server.
In order to solve the technical problems, the invention adopts the technical scheme that:
in a first aspect, the invention discloses an application layer registration keep-alive system, which comprises a server, a client and a Channel link connected between the server and the client, wherein the server comprises an I/O thread transmission module, and the I/O thread transmission module is provided with an internet transmission layer interface and is used for receiving messages from the client or sending messages to the client; the client comprises a message classification processing module, a message annular queue, a registration management module and a message sending interface, wherein the message classification processing module is used for performing classification processing according to message types, the message annular queue is used for transferring messages, and the registration management module is used for processing registration messages and sending the registration messages to the server through the message sending interface; the Channel link comprises a system processing class and a custom processing class, the custom processing class is positioned behind the system processing class, the system processing class is used for analyzing and coding the http protocol to the websocket protocol, and the custom processing class is used for analyzing and coding the custom message.
As a preferred scheme, the system processing class comprises an http server code class, an http object aggregator class and a websocket server class which are connected in sequence, and the custom processing class comprises a custom idlestatehandle class, a custom heartbeat timeout processing class and a custom message processing class.
As a preferred scheme, the communication protocol on the Channel link includes an underlying communication protocol and a custom application layer protocol, the custom application layer protocol includes a magic field, a message length, a version number, a protocol type, a sequence number, a user identity, and a Body content, the magic field is used to identify the protocol header content, the protocol type is used to distinguish the message type, the sequence number is used to determine the matching of the request and the response, the user identity is used to distinguish different users, and the Body content is used to customize the content.
In a second aspect, the present invention discloses an application layer registration keep-alive method, which runs on any one of the above registration keep-alive systems, and is characterized in that the method includes the following steps: s100, receiving a message from a network, and sending the message to a client through an I/O thread transmission module, wherein the message comprises wss message bodies and custom message bodies which are respectively formulated by a bottom communication protocol and a custom application layer protocol; s200, analyzing and coding the message through a system processing class, and sending the self-defined message body to a self-defined processing class after the wss message body is stripped; s300, the self-defined processing class performs read/write timeout check and heartbeat timeout processing on the self-defined message body; and S400, sending the processed custom message body to a message annular queue, forwarding the message annular queue to a message classification processing module, and performing classification processing according to the type of the custom message body.
Preferably, the read/write timeout checking and heartbeat timeout processing includes: s301, receiving a message event, judging whether the message event is an overtime event or not through a user-defined IdleStateHandler class, if so, performing the step S302, and if not, performing the step S303; s302, judging whether the message event is self-defined message read/write overtime or not through a self-defined heartbeat overtime processing class, if so, constructing a self-defined message content identifier as link read/write overtime, transmitting the link read/write overtime to the self-defined message processing class, and if not, directly ending the process;
s303, judging whether the message event needs to be processed, if so, forwarding the message event to the next user-defined message processing class; if not, the printing message is directly discarded.
Preferably, a timer is used to record the sending time of the message event, if the sending time exceeds a set time threshold, the message event is a timeout event, and the set time threshold is at least the time for performing 2 refresh requests.
As a preferred scheme, the method further comprises a login process, specifically: s501, receiving user information, searching whether the user information exists in a registration management module according to a user identity of the user information, if so, performing S502, and if not, performing S503; s502, judging whether the user information carries authentication information, if so, performing step S504, and if not, performing step S503; s503, updating and recording the user login link information, generating an authentication random code, and simultaneously sending a response message to the client for the next authentication; s504, authenticating the user, judging whether the authentication is passed, if so, performing the next step, otherwise, failing to authenticate, returning a failure response, and recycling resources; and S505, updating the user state to be an online state, and informing the client of successful login in response.
As a preferred scheme, the method further comprises a refreshing process, specifically: s601, searching whether the user information exists in the registration management module according to the user identity, if so, performing step S602, and if not, performing step S604; s602, searching for a user state, and responding to a refreshing process; s603, judging whether the user is in a successful registration state, if so, performing step S605, otherwise, performing step S604; s604, returning an error response, directly closing the link and recovering the resources, wherein the error response comprises user absence, registration state error or illegal message; s605, refreshing the user registration state, and clearing the user refresh failure count.
In a third aspect, the invention discloses an electronic device comprising a processor and a non-volatile memory storing computer instructions, wherein when the computer instructions are executed by the processor, the electronic device performs any one of the methods described above.
In a fourth aspect, the invention discloses a storage medium having stored therein a computer program which, when executed, implements the method of any one of the above.
Compared with the prior art, the invention has the beneficial effects that: the framework of the application layer registration keep-alive system is composed of an application server, a user-defined protocol and a client APP, wherein communication is carried out between the server and the client through user-defined messages, the communication protocol comprises a bottom layer communication protocol and a user-defined application layer protocol, the bottom layer communication protocol ensures that a communication link is normal, the communication content is completed through the user-defined application layer protocol, each developer or team can be defined according to own needs, the use is convenient and flexible, and most application scene requirements can be met. By adopting the bottom communication protocol and the custom application layer protocol, after the user is successfully registered, the application layer message is sent regularly to ensure that the communication between the client and the server is in an online state, and other APPs do not occupy server resources for a long time after accessing the bottom protocol due to the fact that the other APPs do not have correct custom format protocols and updating mechanisms, so that the server resources are saved.
Drawings
The disclosure of the present invention is illustrated with reference to the accompanying drawings. It is to be understood that the drawings are designed solely for the purposes of illustration and not as a definition of the limits of the invention. In the drawings, like reference numerals are used to refer to like parts. Wherein:
fig. 1 is a schematic structural diagram of an application layer registration keep-alive system according to an embodiment of the present invention;
fig. 2 is a schematic diagram of a relationship among a Channel link, a Channel pilot component, and a Channel handler processing class according to an embodiment of the present invention;
fig. 3 is an architecture diagram of a channelpinine component, an application layer message processing module, and an I/O thread transmission module according to an embodiment of the present invention;
fig. 4 is a schematic structural diagram of a channelpinine assembly according to an embodiment of the present invention;
fig. 5 is a flowchart illustrating an application layer registration keep-alive method according to an embodiment of the present invention;
FIG. 6 is a flow chart illustrating read/write timeout checking and heartbeat timeout processing according to an embodiment of the present invention;
FIG. 7 is a schematic diagram of a login process according to an embodiment of the present invention;
FIG. 8 is a diagram illustrating a refresh process according to an embodiment of the present invention.
Detailed Description
It is easily understood that according to the technical solution of the present invention, a person skilled in the art can propose various alternative structures and implementation ways without changing the spirit of the present invention. Therefore, the following detailed description and the accompanying drawings are merely illustrative of the technical aspects of the present invention, and should not be construed as all of the present invention or as limitations or limitations on the technical aspects of the present invention.
An embodiment according to the invention is shown in connection with fig. 1 to 3. An application layer registration keep-alive system comprises a server, a client and a Channel link connected between the server and the client.
In the embodiment of the invention, a linux system-based netty open-source framework adopting java language is selected as a server. The netty open source framework provides many common protocol supports such as tcp, udp, http, websocket, ssl, etc., and is capable of codec encoding and de-coding stream throttling. The server comprises an I/O thread transmission module, and the I/O thread transmission module is provided with an internet transmission layer interface and is used for receiving messages from the client or sending messages to the client.
The application layer message processing module on the client side adopts an independent thread mode, and if the traffic is large, the multi-thread concurrent mode processing can be considered. The application layer message processing module comprises a message classification processing module, a message annular queue, a registration management module and a message sending interface, wherein the message classification processing module is used for performing classification processing according to message types, the message annular queue is used for transferring messages, and the registration management module is used for processing registration messages and sending the registration messages to a server through the message sending interface.
Referring to fig. 2, each user accessing the system, the netty open source framework interfaces a Channel link corresponding to the netty open source framework, the Channel link is associated with I/O operation of the link and is used for managing the state of the link, and each Channel link has one or only one channelpinine component corresponding to the Channel link. The channelpinine component consists of a plurality of ChannelHandler handling classes, one ChannelHandler handling class may contain one inbound handler or outboundhandler or both. The ChannelHandler handling class is stored in a doubly linked list, i.e. after an inbound message (message event) is received, the message event is transmitted from the head to the tail, and an outbound message is transmitted from the tail to the head. The two types of handlers, inboundhandler and outbouthandler, do not interfere with each other.
The Channel link comprises a system processing class and a custom processing class, and the custom processing class is positioned behind the system processing class, so that the read/write timeout is ensured to only aim at user custom messages rather than http or websocket messages. The system processing class is used for analyzing and coding from an http protocol to a websocket protocol, and the user-defined processing class is used for analyzing and coding user-defined messages.
Referring to fig. 4, the system processing classes include an http server code class, an http object assembler class, and a websocket server handler class, which are connected in sequence, and the custom processing classes include a custom idlestatehandle class, a custom heartbeat timeout processing class, and a custom message processing class. The custom message handling class is used to decode the message into a message format that the upper layer application can handle, while encoding the server upper layer down-sent message into a user-defined format and sending it to the final client app via wss communication protocol.
When the client or the APP communicates with the server, the client or the APP generally communicates with the server based on a common protocol, and in this embodiment, a bottom layer communication protocol + a custom application layer protocol is used for communication. The communication link is ensured to be normal by the bottom layer communication protocol, the communication content is completed by the user-defined application layer protocol, and each developer or team can define the communication link according to the requirement, so that the use is convenient and flexible. After the user is successfully registered, the application layer message is sent regularly to ensure that the communication between the client and the server is in an online state, and other APPs do not occupy server resources for a long time after accessing a bottom layer protocol due to the fact that the other APPs do not have correct custom format protocols and updating mechanisms, so that the server resources are saved.
Specifically, the communication protocol on the Channel link includes a bottom layer communication protocol and a custom application layer protocol, where the bottom layer communication protocol is a wss (web Socket secure) communication protocol, and can support multiple apps and meet the requirement of communication data encryption.
The self-defined application layer protocol comprises a magic field, message length, version number, protocol type, sequence number, user identity identification and Body content. The magic field is used for identifying the content of the protocol header and occupies 4 bytes; the length of the message occupies 2 bytes and can be automatically expanded according to the requirement; the protocol type is used to distinguish message types, i.e. messages for distinguishing different types of requests or responses of users, for example: read-write timeout message type; the sequence number is used to determine the match of the request and the response; the user identity is used for distinguishing different users; body uses the json format for custom content. As shown in the table below.
The format of the whole self-defined message adopts a fixed message header and a variable-length message body, and can basically meet the requirements of most application scenes.
Referring to fig. 5, the invention discloses an application layer registration keep-alive method, which runs on a registration keep-alive system, and comprises the following steps:
s100, receiving a message from a network, and sending the message to a client through an I/O thread transmission module, wherein the message comprises wss message bodies and custom message bodies formulated by a bottom layer communication protocol and a custom application layer protocol respectively.
S200, analyzing and coding the message through the system processing class, and sending the custom message body to the custom processing class after the wss message body is stripped. Namely: the parsing and encoding process from the http protocol to the websocket protocol is completed through the http server codec class, the http objectagregger class and the websocket server handler class. The custom processing class is located behind the system processing class, ensuring that read/write timeouts are only directed to user custom messages, not http or websocket messages.
S300, the user-defined processing class performs read/write timeout check and heartbeat timeout processing on the user-defined message body.
And S400, sending the processed custom message body to a message annular queue, forwarding the message annular queue to a message classification processing module, and performing classification processing according to the type of the custom message body.
Referring to fig. 6, the read/write timeout checking and heartbeat timeout processing includes:
s301, receiving the message event, judging whether the message event is a timeout event through the user-defined IdleStateHandler class, if so, performing the step S302, and if not, performing the step S303.
And recording the sending time of the message event by adopting a timer, wherein if the sending time exceeds a set time threshold, the message event is an overtime event, and the set time threshold is at least the time for carrying out 2 times of refreshing requests. Namely: the Idlstatehandler is a handler for reading/writing timeout processing of application layer messages, and has the function of checking the reading/writing time of an application layer link of the link, and reporting an idleStateEvent to a subsequent custom heartbeat timeout processing class when one of the reading, writing or reading and writing exceeds a set time threshold according to the setting of a user.
S302, judging whether the message event is the self-defined message read/write overtime through the self-defined heartbeat overtime processing class, namely firstly judging whether the message event is the self-defined message and then judging whether the message event is the read overtime message or the write overtime message. If yes, the self-defined message content mark is constructed to be the link read/write overtime, and the link read/write overtime is transmitted to the self-defined message processing class, and if not, the process is ended directly. Specifically, whether the message event is the self-defined message type is judged according to the magic field of the self-defined application layer protocol, and whether the message event is the read timeout message or the write timeout message is judged by looking up the field of the protocol type. If the message event is not a message beginning with the magic field, the message event is considered not to be a custom protocol message.
S303, judging whether the message event needs to be processed, if so, forwarding the message event to the next user-defined message processing class; if not, the printing message is directly discarded. There may be multiple custom message handling classes, for example: the user needs to process a special field or a message type in the user-defined message event, and after the current user-defined message processing class, the user may also need to process other (handler) processing classes, and at this time, after the current user-defined message processing class is completed, the user-defined message event is forwarded to the next user-defined message processing class for processing, or the user-defined message event is directly transmitted to the following client side APP for analysis and business processing.
According to the read/write overtime event of the user-defined message on the link, whether the client has the keep-alive message in the application layer can be judged. If the server does not receive the keep-alive message of the client, no response is sent. The client side may be considered to have timed out once at this time. The application layer sets the count, and then the heartbeat timeout mechanism processing can be realized.
In addition, when the server closes the link or the network causes the link to be broken, the application layer of the client generally needs to be notified that the link has been broken. The hang-up message and the user-defined timeout event processing are both set in the heartbeat timeout processing module and processed through different interfaces, and the steps S100-S400 are used when the message is read. If the message is a hang-up message, the message needs to be converted into a user-defined message to inform the application layer, and other messages are directly transmitted to the application layer.
In the embodiment of the invention, the message of the registration part is sent to the registration management module for processing, and the handler (processing class) of the data and the link of the registered user is stored, when the message needs to be sent to a certain client, the link mode of the user is obtained by obtaining the registration management information of the user, and the interface for sending the data is called to send the data to the corresponding client or app.
Referring to fig. 7, the method further includes a login process, specifically:
s501, receiving the user information, searching whether the user information exists in the registration management module according to the user identity of the user information, if so, performing S502, and if not, performing S503.
And S502, judging whether the user information carries the authentication information, if so, performing the step S504, and if not, performing the step S503.
S503, updating and recording the user login link information, generating an authentication random code, and simultaneously sending a response message to the client for the next authentication.
S504, the user is authenticated, whether the authentication is passed or not is judged, if yes, the next step is carried out, otherwise, the authentication is failed, a failure response is returned, and resources are recycled.
And S505, updating the user state to be an online state, and informing the client of successful login in response.
And when the user is successfully registered and logged in, the registration management module of the application layer records the information of the user. When information needs to be sent to a user, the registration management module needs to be searched according to the user identity, and the information is sent to the client according to the link information stored in the registration management module.
Referring to fig. 8, the method further includes a refresh process, specifically:
s601, searching whether the registration management module has user information according to the user identity, if so, performing step S602, and if not, performing step S604.
S602, searching the user state and responding to the refreshing process.
S603, determine whether the user is in a registration success state, if yes, go to step S605, and if no, go to step S604.
S604, an error response is returned, the link is directly closed, and resources are recycled, wherein the error response comprises user absence, registration state error or illegal message.
S605, refreshing the user registration state, and clearing the user refresh failure count.
User information must exist when refreshing the user state, and the record of the refresh failure is generally cleared when refreshing. After the registration is successful, it may happen that the client fails to refresh due to its own reason or network reason within a specified time, and in order to prevent failure, the resource is released immediately, generally fault-tolerant processing is performed, and the server generally releases the resource after more than 2 registration failure times.
The invention also discloses an electronic device, which comprises a processor and a nonvolatile memory for storing computer instructions, wherein when the computer instructions are executed by the processor, the electronic device executes any one of the methods.
The invention also discloses a storage medium, wherein a computer program is stored in the storage medium, and the computer program can realize the method of any item when being executed.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the system, the electronic device and the storage medium described above may refer to corresponding processes in the foregoing method embodiments, and are not described herein again.
It should be understood that the integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention essentially or partially contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
The technical scope of the present invention is not limited to the above description, and those skilled in the art can make various changes and modifications to the above-described embodiments without departing from the technical spirit of the present invention, and such changes and modifications should fall within the protective scope of the present invention.
Claims (10)
1. An application layer registration keep-alive system is characterized by comprising a server and a client, and a Channel link connected between the server and the client,
the server comprises an I/O thread transmission module, and the I/O thread transmission module is provided with an internet transmission layer interface and is used for receiving messages from the client or sending messages to the client;
the client comprises a message classification processing module, a message annular queue, a registration management module and a message sending interface, wherein the message classification processing module is used for performing classification processing according to message types, the message annular queue is used for transferring messages, and the registration management module is used for processing registration messages and sending the registration messages to the server through the message sending interface;
the Channel link comprises a system processing class and a custom processing class, the custom processing class is positioned behind the system processing class, the system processing class is used for analyzing and coding the http protocol to the websocket protocol, and the custom processing class is used for analyzing and coding the custom message.
2. The application layer registration keep-alive system of claim 1, wherein the system handling classes comprise an http server code class, an http objectaggregator class, and a websocket serverhandler class, which are connected in sequence, and the custom handling classes comprise a custom IdleStateHandler class, a custom heartbeat timeout handling class, and a custom message handling class.
3. The application layer register-keep-alive system of claim 1, wherein the communication protocols on the Channel link include an underlying communication protocol and a custom application layer protocol, the custom application layer protocol including a magic field, a message length, a version number, a protocol type, a sequence number, a user identity, and Body content, the magic field identifying protocol header content, the protocol type identifying message type, the sequence number identifying matching of requests and responses, the user identity identifying different users, and the Body content identifying custom content.
4. An application layer registration keep-alive method running on a registration keep-alive system according to any one of claims 1 to 3, the method comprising the steps of:
s100, receiving a message from a network, and sending the message to a client through an I/O thread transmission module, wherein the message comprises wss message bodies and custom message bodies which are respectively formulated by a bottom communication protocol and a custom application layer protocol;
s200, analyzing and coding the message through a system processing class, and sending the self-defined message body to a self-defined processing class after the wss message body is stripped;
s300, the self-defined processing class performs read/write timeout check and heartbeat timeout processing on the self-defined message body;
and S400, sending the processed custom message body to a message annular queue, forwarding the message annular queue to a message classification processing module, and performing classification processing according to the type of the custom message body.
5. An application layer registration keep-alive method as claimed in claim 4, wherein the read/write timeout check and heartbeat timeout process comprises:
s301, receiving a message event, judging whether the message event is an overtime event or not through a user-defined IdleStateHandler class, if so, performing the step S302, and if not, performing the step S303;
s302, judging whether the message event is self-defined message read/write overtime or not through a self-defined heartbeat overtime processing class, if so, constructing a self-defined message content identifier as link read/write overtime, transmitting the link read/write overtime to the self-defined message processing class, and if not, directly ending the process;
s303, judging whether the message event needs to be processed, if so, forwarding the message event to the next user-defined message processing class; if not, the printing message is directly discarded.
6. The method for registration keep-alive at application layer according to claim 5, wherein a timer is used to record the sending time of the message event, if the sending time exceeds a set time threshold, the message event is a timeout event, and the set time threshold is at least the time for 2 refresh requests.
7. The application layer registration keep-alive method according to claim 4, further comprising a login process, specifically:
s501, receiving user information, searching whether the user information exists in a registration management module according to a user identity of the user information, if so, performing S502, and if not, performing S503;
s502, judging whether the user information carries authentication information, if so, performing step S504, and if not, performing step S503;
s503, updating and recording the user login link information, generating an authentication random code, and simultaneously sending a response message to the client for the next authentication;
s504, authenticating the user, judging whether the authentication is passed, if so, performing the next step, otherwise, failing to authenticate, returning a failure response, and recycling resources;
and S505, updating the user state to be an online state, and informing the client of successful login in response.
8. The application layer registration keep-alive method according to claim 4, further comprising a refresh process, specifically:
s601, searching whether the user information exists in the registration management module according to the user identity, if so, performing step S602, and if not, performing step S604;
s602, searching for a user state, and responding to a refreshing process;
s603, judging whether the user is in a successful registration state, if so, performing step S605, otherwise, performing step S604;
s604, returning an error response, directly closing the link and recovering the resources, wherein the error response comprises user absence, registration state error or illegal message;
s605, refreshing the user registration state, and clearing the user refresh failure count.
9. An electronic device comprising a processor and a non-volatile memory having stored thereon computer instructions, which, when executed by the processor, cause the electronic device to perform the method of any of claims 4-8.
10. A storage medium, characterized in that a computer program is stored in the storage medium, which computer program, when executed, implements the method of any one of claims 4-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111556592.1A CN114205167A (en) | 2021-12-17 | 2021-12-17 | Application layer registration keep-alive method, system, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111556592.1A CN114205167A (en) | 2021-12-17 | 2021-12-17 | Application layer registration keep-alive method, system, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114205167A true CN114205167A (en) | 2022-03-18 |
Family
ID=80655236
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111556592.1A Pending CN114205167A (en) | 2021-12-17 | 2021-12-17 | Application layer registration keep-alive method, system, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114205167A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114928663A (en) * | 2022-06-02 | 2022-08-19 | 蜂助手股份有限公司 | Method and device for recognizing callback message |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103812878A (en) * | 2014-03-17 | 2014-05-21 | 哈尔滨理工大学 | Android-based road condition information interaction system |
| CN110719283A (en) * | 2019-10-11 | 2020-01-21 | 深圳心跳智能科技有限公司 | Intelligent fire hydrant system and online registration method thereof |
| CN113315684A (en) * | 2021-07-30 | 2021-08-27 | 武汉中科通达高新技术股份有限公司 | Communication management method and device, electronic equipment and storage medium |
-
2021
- 2021-12-17 CN CN202111556592.1A patent/CN114205167A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103812878A (en) * | 2014-03-17 | 2014-05-21 | 哈尔滨理工大学 | Android-based road condition information interaction system |
| CN110719283A (en) * | 2019-10-11 | 2020-01-21 | 深圳心跳智能科技有限公司 | Intelligent fire hydrant system and online registration method thereof |
| CN113315684A (en) * | 2021-07-30 | 2021-08-27 | 武汉中科通达高新技术股份有限公司 | Communication management method and device, electronic equipment and storage medium |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114928663A (en) * | 2022-06-02 | 2022-08-19 | 蜂助手股份有限公司 | Method and device for recognizing callback message |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8332476B2 (en) | Social network virtual private network | |
| ES2525527T3 (en) | Apparatus and procedure to control and audit the activity of an inherited environment | |
| US8769278B2 (en) | Apparatus and method for efficiently and securely exchanging connection data | |
| US9654551B2 (en) | Apparatus and method for inviting users to online sessions | |
| US9118690B2 (en) | Apparatus and method for matching users for online sessions | |
| US8438294B2 (en) | Application programming interface, system, and method for collaborative online applications | |
| US8819244B2 (en) | Apparatus and method for establishing and utilizing backup communication channels | |
| CN105763634B (en) | A kind of service implementing method and device based on TCP long connection | |
| CN114124929A (en) | Cross-network data processing method and device | |
| CN108156223A (en) | A kind of accurate supplying system of message based on websocket and method | |
| US9723480B2 (en) | Information processing device, server device, data communication system, data communication method, and computer-readable storage medium storing data communication program | |
| CN114205167A (en) | Application layer registration keep-alive method, system, electronic equipment and storage medium | |
| CN111367479A (en) | Cloud printing method, printing method of cloud printing service platform and storage medium | |
| US20070115917A1 (en) | MTOM data transfer via TCP | |
| CN108198549A (en) | Equipment control method, device, storage medium, server and user terminal | |
| JP2009205364A (en) | Life-and-death monitoring method, monitored device, monitor and life-and-death monitoring program | |
| CN115348333B (en) | Data transmission method, system and equipment based on UDP double-end communication interaction | |
| US7693936B2 (en) | Messaging schema for services interaction on prepaid and subscription system | |
| CN109361591B (en) | Personal message aggregation system based on plug-in | |
| CN113852610B (en) | Message processing method, device, computer equipment and storage medium | |
| KR100727057B1 (en) | Method And System For Checking Message Status | |
| US20170318063A1 (en) | System and method for reliable messaging between application sessions across volatile networking conditions | |
| CN106789549B (en) | Converged communication method and device | |
| CN111182047B (en) | Method and system for transferring files between large data platforms across a network | |
| US20070150959A1 (en) | Inter-process authentication via a copyrighted value |
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 | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20240514 Address after: 518000 2101, No. 100, Zhihe Road, Dakang community, Yuanshan street, Longgang District, Shenzhen, Guangdong Applicant after: BANGYAN TECHNOLOGY Co.,Ltd. Country or region after: China Address before: 518000 a2101, building 9, zone 2, Shenzhen Bay science and technology ecological park, No. 3609 Baishi Road, high tech Zone community, Yuehai street, Nanshan District, Shenzhen, Guangdong Applicant before: Shenzhen Jiancheng Yunshi Technology Co.,Ltd. Country or region before: China |
|
| TA01 | Transfer of patent application right |