CN112363849A - Lightweight service interaction protocol method in tactical environment - Google Patents
Lightweight service interaction protocol method in tactical environment Download PDFInfo
- Publication number
- CN112363849A CN112363849A CN202011146265.4A CN202011146265A CN112363849A CN 112363849 A CN112363849 A CN 112363849A CN 202011146265 A CN202011146265 A CN 202011146265A CN 112363849 A CN112363849 A CN 112363849A
- Authority
- CN
- China
- Prior art keywords
- message
- request
- protocol
- connection
- service
- 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
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
Abstract
The invention relates to the technical field of wireless communication, and discloses a lightweight service interaction protocol method in a tactical environment, which comprises a protocol format design method and a service interaction flow control method, wherein the protocol format design method is adapted to a narrow-band environment by shortening a protocol format, the shortened protocol format comprises a message header and an optional message body, the message header comprises a protocol identifier, a protocol version number, a message type, an identifier bit, an encryption state, a compression state and a message total length, the protocol identifier and the protocol version number respectively occupy 1 byte, the message type and the identifier bit occupy 1 byte, the encryption state and the compression state occupy 1 byte, and the message total length occupies 1-4 bytes. The invention can adapt to the bandwidth characteristics of various communication channels in a tactical communication network and realize the interactive access of remote services on an unstable communication link on the premise of low overhead.
Description
Technical Field
The invention relates to the technical field of wireless communication, in particular to a lightweight service interaction protocol method in a tactical environment.
Background
With the rapid development of information technology and internet technology, especially the increasingly widespread application of new technologies such as cloud computing, big data, artificial intelligence and the like, tactical communication network architecture is gradually changed into an elastic network architecture facing resources and services, clouds and terminals.
With the popularization of distributed calling, many efficient RPC schemes are currently in use. The major notable ones are Apache thread, Apache Avro and Protocol Buffers, but it is difficult to apply directly in the high dynamic, weakly connected, narrow bandwidth environment of a tactical network.
Disclosure of Invention
In order to solve the above problems, the present invention provides a lightweight service interaction protocol method in a tactical environment, which can adapt to bandwidth characteristics of various communication channels in a tactical communication network, and implement remote service interaction access on an unstable communication link on the premise of low overhead.
The invention relates to a lightweight service interaction protocol method in a tactical environment, which shortens a protocol format to adapt to a narrow-band environment, wherein the shortened protocol format at least comprises a message header, the message header comprises a protocol identifier, a protocol version number, a message type, an identifier bit, an encryption state, a compression state and a message total length, the message type comprises a request, a reply, a heartbeat request, a heartbeat response and disconnection, the identifier bit comprises a message which is sent for the first time and is sent for retransmission, the encryption state comprises a plaintext and a ciphertext, and the compression state comprises an uncompressed state and a compressed state; the protocol mark and the protocol version number respectively occupy 1 byte, the message type and the identification bit occupy 1 byte, the encryption state and the compression state occupy 1 byte, and the total length of the message occupies 1-4 bytes.
Furthermore, the total length of the message adopts a variable length coding scheme, the highest bit of each byte represents whether the next byte exists, and the rest 7 bits represent data; when the total message length is less than 128 bytes, only one byte is required to represent the total message length.
Further, when the encryption state is plaintext, the sender may not have the ability to receive the ciphertext and the sender may have the ability to receive the ciphertext, and the encoding is performed separately.
Further, when the compression state is uncompressed, the sender may not have the capability of receiving the compressed message and the sender may have the capability of receiving the compressed message, and the sender may perform encoding separately.
Further, the shortened protocol format further comprises a message body, wherein different message types correspond to different message bodies, the message body comprises a request message, a reply message, a heartbeat request message, a heartbeat response message and a disconnection message, the request message is a message sent by the client to the server, and the reply message is a message sent by the server to the client; the heartbeat request message, the heartbeat response message and the disconnection message are sent to the server by the client side or sent to the client side by the server, the heartbeat request message, the heartbeat response message and the disconnection message are only effective when the connection is oriented, and the length of the message body is 0.
Further, if compression is adopted, the message body comprises two parts, namely the original length of the message body before compression, and the compressed message body data; if no compression is employed, the message body portion includes only uncompressed message body data.
Further, the request message includes a request ID, a service ID, and a join list, and all the value types are stored in the small terminal.
Further, the reply message includes a request ID, a response status, and an exit list, and all value types are stored using the small end.
Further, the flow control of the service interaction comprises the following steps:
step one, a client initiates service calling, a request priority queue is established according to calling requests, another thread scans the queue, the service corresponding to each request and the service end to which the service belongs are asynchronously inquired, the mapping between the requests and the service end is established, and a plurality of requests can be mapped to the same service end;
step two, establishing connection for different servers respectively, and establishing a connection thread pool asynchronously; the method comprises the steps that a communication mode combining long connection and short connection is adopted, network situation information between a client and a server is sensed in real time, the information quantity of service interaction including bandwidth and time delay is combined for evaluation, and the long connection or short connection mode is automatically decided;
step three, asynchronously sending a service request to a server through a connection thread, establishing a link monitor for each connection, and monitoring and judging an operation result; if the operation is found to be unsuccessful, adding a message of failed transmission or overtime request to a retransmission queue; for a retransmission message, the message identification bit is coded to be 1, the server receives and identifies a retransmission message request, firstly judges whether the request is received for the first time, if not, the request response is directly taken out from the buffer, and the message identification bit is coded to be 1 and sent to the client;
step four, aiming at long connection, starting heartbeat detection, adopting a mechanism of link reading idle and heartbeat detection, wherein the link reading idle means that no information is read by the link duration time T; when no new request arrives in the connection within the time M, the connection is actively closed, and resources are released; when the channel quality is detected to be reduced to a preset threshold value, the heartbeat detection failure frequency or the service request failure frequency reaches a preset value, the current long connection is closed, and the short connection mode is used for communication; and aiming at the short connection, when the channel quality is detected to be improved to a preset threshold value, the long connection is tried to be established with the server side, and the communication is carried out in a long connection mode.
The invention has the beneficial effects that: the invention can adapt to the bandwidth characteristics of various communication channels in a tactical communication network, realizes the interactive access of remote services on an unstable communication link on the premise of low overhead, and specifically comprises the following steps:
the invention designs the protocol format into the structure of message head and optional message body, when the length of the message body is 0, a message only contains the total length of the message with 4 bytes of fixed head and 1 byte of variable length, and the short message can better adapt to the tactical narrow-band environment and reduce the transmission overhead.
The total length of the message adopts a variable length coding scheme, the highest bit of each byte represents whether the next byte exists, and the rest 7 bits represent data; when the total length of the message is less than 128 bytes, only one byte is needed to represent the total length of the message, so that large expenses can be saved.
When compression is adopted, the message body of the invention not only comprises compressed message body data, but also retains the original length of the message body before compression, thus leading a message receiver to be capable of allocating proper memory space to store the decompressed data.
The invention establishes a link monitor for each connection between the client and the server, monitors and judges the operation result, and can better adapt to the weak connection characteristic of the tactical network.
The invention starts the heartbeat detection aiming at the long connection, and adopts a mechanism of 'link reading idle' + 'heartbeat detection'; aiming at the short connection, when the channel quality is detected to be improved to the preset threshold value, the long connection is tried to be established with the server side, and the communication is carried out in a long connection mode, so that the high dynamic characteristic of the tactical network can be better adapted.
Drawings
FIG. 1 is a diagram of a protocol format according to the present invention;
FIG. 2 is a schematic diagram of a request message according to the present invention;
FIG. 3 is a diagram of a reply message of the present invention;
FIG. 4 is a schematic view of an interaction flow of the present invention;
FIG. 5 is a diagram of an interaction example of the present invention.
Detailed Description
In order to more clearly understand the technical features, objects, and effects of the present invention, specific embodiments of the present invention will now be described. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present invention without making any creative effort, shall fall within the protection scope of the present invention.
The invention provides a lightweight service interaction protocol method in a tactical environment, which comprises a protocol format design method and a service interaction flow control method, wherein the protocol format design method comprises the following steps:
the protocol format design method of the invention adapts to the narrow-band environment by shortening the protocol format, the shortened protocol format comprises a message head and an optional message body, as shown in figure 1, the message head comprises a protocol identifier, a protocol version number, a message type, an identifier bit, an encryption state, a compression state and a message total length, the protocol identifier and the protocol version number respectively occupy 1 byte, the message type and the identifier bit occupy 1 byte, the encryption state and the compression state occupy 1 byte, and the message total length occupies 1-4 bytes. When the length of the message body is 0, one message only contains the total length of a message with 4 bytes of fixed heads and 1 byte of variable length, and the short message can better adapt to a tactical narrow-band environment and reduce the transmission overhead.
As shown in table 1, the message types include request, reply, heartbeat request, heartbeat response, and disconnection, and content to be augmented.
TABLE 1 message types
| Encoding | |
| 1 | Request for |
| 2 | |
| 3 | Heartbeat request |
| 4 | |
| 5 | |
| 0,6-15 | Reserved for later expansion |
As shown in table 2, the identification bits include the first transmission and retransmission of the packet, and the content to be extended. Specifically, when the compression state is uncompressed, the sender may not have the capability of receiving the compressed message and the sender may have the capability of receiving the compressed message, and the sender may perform encoding separately.
TABLE 2 identification bits
| | Status identification | |
| 0 | The message is sent for the |
|
| 1 | The message is transmitted for retransmission | |
| 2-15 | Reserved for later expansion |
As shown in table 3, the encryption state includes plaintext and ciphertext, and the compression state includes uncompressed and compressed, and the content to be extended. Specifically, when the encryption state is plaintext, the sender may not have the ability to receive ciphertext and the sender may have the ability to receive ciphertext, and encoding is performed separately.
Table 3 encryption status
The total length of the message adopts a variable length coding scheme, the highest bit of each byte represents whether the next byte (1 has 0 or not), and the rest 7 bits represent data (the highest bit of each byte is removed during calculation); when the total length of the message is less than 128 bytes, only one byte is needed to represent the total length of the message, so that great expense can be saved, and the length range which can be represented by the coding scheme is shown in the table 5.
TABLE 5 Length coding
| Number of bytes | Minimum value | |
| 1 | 0(0x00) | 127(0x7F) |
| 2 | 128(0x80,0x01) | 16383(0xFF,0x7F) |
| 3 | 16384(0x80,0x80,0x01) | 2097151(0xFF,0xFF,0x7F) |
| 4 | 2097152(0x80,0x80,0x80,0x01) | 268435455(0xFF,0xFF,0xFF,0x7F) |
If compression is adopted, the message body comprises two parts, namely the original length of the message body before compression, the coding scheme and the total length of the message, so that a message receiver can allocate a proper memory space to store decompressed data; the second is compressed message body data. If no compression is employed, the message body portion includes only uncompressed message body data.
Different message types correspond to different message bodies, and are respectively described according to the message types.
1) Request message
The request message is a message sent by the client to the server, and includes a request ID, a service ID, a reference list, and the like, and all value types adopt little-endian (little-endian), as shown in fig. 2.
2) Reply message
The reply message is a message sent by the server to the client, and includes a request ID, a response status, an argument list, and the like, and all value types adopt little-endian (little-endian), as shown in fig. 3.
The response status may be as follows, as shown in table 6.
TABLE 6 response State coding
| Answer state | Encoding | Description of the invention |
| Successful | 0 | Replies with a positive response and returns the out-going parameters |
| Service ID does not exist | 1 | Service ID does not exist |
| Error of entering into | 2 | Error of entering into |
| |
3 | Other exceptions, returning detailed information via character string |
3) Heartbeat request, heartbeat response, disconnect message
The heartbeat request, heartbeat response and disconnection messages are only effective when the messages are oriented to connection and are sent to the server by the client side or the server, and the message body length of the messages is 0.
Service interactive access is essentially a request-response message stream, and measures such as disconnection reconnection, overtime retransmission, abnormal retransmission and the like are used among services to ensure that the requests are correctly processed under the condition of packet loss, so that efficient transmission of service requests and responses is ensured.
As shown in fig. 4, the flow control method of service interaction of the present invention includes the following steps:
step one, a client initiates service calling, a request priority queue is established according to calling requests, another thread scans the queue, the service corresponding to each request and the service end to which the service belongs are asynchronously inquired, the mapping between the requests and the service end is established, and a plurality of requests can be mapped to the same service end;
step two, establishing connection for different servers respectively, and establishing a connection thread pool asynchronously; generally, a communication protocol corresponding to a long connection is TCP, a communication protocol corresponding to a short connection is UDP, a tactical communication network integrates a plurality of communication means, and various communication modes are different in bandwidth delay and the like, so that the invention adopts a communication mode combining the long connection and the short connection, evaluates by sensing network situation information between a client and a server in real time, including bandwidth and delay, in combination with the information amount of service interaction, and automatically decides to adopt the long connection or the short connection mode;
step three, asynchronously sending a service request to a server through a connection thread, establishing a link monitor for each connection, and monitoring and judging an operation result; if the operation is found to be unsuccessful, adding a message of failed transmission or overtime request to a retransmission queue; for a retransmission message, the message identification bit is coded to be 1, the server receives and identifies a retransmission message request, firstly judges whether the request is received for the first time, if not, the request response is directly taken out from the buffer, and the message identification bit is coded to be 1 and sent to the client; the design of the monitor can better adapt to the weak connection characteristic of a tactical network;
step four, aiming at long connection, starting heartbeat detection, adopting a mechanism of link reading idle and heartbeat detection, wherein the link reading idle means that no information is read by the link duration time T; when no new request arrives in the connection within the time M, the connection is actively closed, and resources are released; when the channel quality is detected to be reduced to a preset threshold value, the heartbeat detection failure frequency or the service request failure frequency reaches a preset value, the current long connection is closed, and the short connection mode is used for communication; and aiming at the short connection, when the channel quality is detected to be improved to a preset threshold value, the long connection is tried to be established with the server side, and the communication is carried out in a long connection mode. The step design can better adapt to the high dynamic characteristics of the tactical network.
In a preferred embodiment of the present invention, as shown in fig. 5, the method for controlling the flow of service interaction includes the following steps:
step one, a client initiates service calling, a request priority queue is established according to calling requests, a thread 1 scans the queue, services corresponding to each request and a service end to which the service belongs are asynchronously inquired, a mapping list of the requests and the service ends is established, and it is assumed that the requests 1, 3 and 4 correspond to a service end A and the requests 2, 5 and 6 correspond to a service end B.
And step two, establishing connection for different servers respectively, and establishing a connection thread pool asynchronously. The client side senses that the bandwidth of the client side and the bandwidth of the server side A are high and the link quality is good, establishes TCP connection with the server side A, senses that the bandwidth of the client side and the bandwidth of the server side B are narrow and the link is unstable, and transmits data with the server side B by adopting UDP.
And step three, asynchronously sending the service requests 1, 3 and 4 through the TCP connection with the server A, and monitoring and judging the operation result. And the thread connected with the thread pool and corresponding to the server B asynchronously sends the requests 2 and 5 in a UDP mode, supposing that the packet drop of the request 5 sent to the client due to the response packet sent by the server B is overtime, the message identification bit is coded as 1 to be sent again, the server B receives the retransmitted message, finds that the request has responded, does not need repeated calculation, can directly take out the response from the buffer, codes the message identification bit as 1 and sends the response to the client.
And step four, after the service requests 1, 3 and 4 are completed, if the link has no information interaction within the time T (such as 30 seconds), starting a heartbeat detection mechanism, and if 3 times of detection timeout is totally performed during 6 heartbeat periods, considering that the link quality is deteriorated, closing the current long connection and communicating in a UDP (user datagram protocol) mode. If a new request 6 arrives, a TCP connection is established with the server B, and the transmission efficiency is improved. If no new request arrives for the connection at time M (e.g., 60 seconds), the connection is actively closed, resources are released, and the thread is further terminated from the connection thread pool.
The coefficients and parameters given in the above examples are provided to those skilled in the art to realize or use the invention, and the invention is not limited to the values disclosed above, and those skilled in the art can make various modifications or adjustments to the above embodiments without departing from the spirit of the invention, therefore, the scope of the invention is not limited by the above embodiments.
The foregoing is illustrative of the preferred embodiments of this invention, and it is to be understood that the invention is not limited to the precise form disclosed herein and that various other combinations, modifications, and environments may be resorted to, falling within the scope of the concept as disclosed herein, either as described above or as apparent to those skilled in the relevant art. And that modifications and variations may be effected by those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (9)
1. A lightweight service interaction protocol method under tactical environment is characterized in that a protocol format is shortened to adapt to a narrow-band environment, the shortened protocol format at least comprises a message header, the message header comprises a protocol identifier, a protocol version number, a message type, an identification bit, an encryption state, a compression state and a message total length, wherein the message type comprises a request, a reply, a heartbeat request, a heartbeat response and disconnection, the identification bit comprises that the message is sent for the first time and is sent for retransmission, the encryption state comprises a plaintext and a ciphertext, and the compression state comprises uncompressed and compressed; the protocol mark and the protocol version number respectively occupy 1 byte, the message type and the identification bit occupy 1 byte, the encryption state and the compression state occupy 1 byte, and the total length of the message occupies 1-4 bytes.
2. The tactical environment lightweight service interaction protocol method of claim 1, wherein the total length of the message is variable length coded, the highest bit of each byte represents whether there is a next byte, and the remaining 7 bits represent data; when the total message length is less than 128 bytes, only one byte is required to represent the total message length.
3. The tactical environment lightweight service interaction protocol method of claim 1, wherein when the encryption status is plaintext, the sender does not have the capability of receiving ciphertext and the sender has the capability of receiving ciphertext, and encoding is performed separately.
4. The tactical environment lightweight service interaction protocol method of claim 1, wherein said encoding is performed separately for cases where a sender does not have the capability to receive compact messages and for cases where a sender has the capability to receive compact messages when said compression state is uncompressed.
5. The tactical environment lightweight service interaction protocol method according to any one of claims 1 to 4, wherein the shortened protocol format further comprises a message body, different message types correspond to different message bodies, the message body comprises a request message, a reply message, a heartbeat request message, a heartbeat response message and a disconnection message, the request message is a message sent by a client to a server, and the reply message is a message sent by the server to the client; the heartbeat request message, the heartbeat response message and the disconnection message are sent to the server by the client side or sent to the client side by the server, the heartbeat request message, the heartbeat response message and the disconnection message are only effective when the connection is oriented, and the length of the message body is 0.
6. The tactical environment lightweight service interaction protocol method of claim 5, wherein if compression is employed, the message body comprises two parts, one is the original length of the message body before compression, and the other is the compressed message body data; if no compression is employed, the message body portion includes only uncompressed message body data.
7. The tactical environment light-weight service interaction protocol method of claim 5, wherein the request message comprises a request ID, a service ID and a reference list, and all value types are stored using a small end.
8. The tactical environment lightweight service interaction protocol method of claim 5, wherein the reply message comprises a request ID, a response status and an exit list, and all value types are stored using a small end.
9. The tactical environment light-weight service interaction protocol method of claim 1, wherein the flow control of service interaction comprises the steps of:
step one, a client initiates service calling, a request priority queue is established according to calling requests, another thread scans the queue, the service corresponding to each request and the service end to which the service belongs are asynchronously inquired, the mapping between the requests and the service end is established, and a plurality of requests can be mapped to the same service end;
step two, establishing connection for different servers respectively, and establishing a connection thread pool asynchronously; the method comprises the steps that a communication mode combining long connection and short connection is adopted, network situation information between a client and a server is sensed in real time, the information quantity of service interaction including bandwidth and time delay is combined for evaluation, and the long connection or short connection mode is automatically decided;
step three, asynchronously sending a service request to a server through a connection thread, establishing a link monitor for each connection, and monitoring and judging an operation result; if the operation is found to be unsuccessful, adding a message of failed transmission or overtime request to a retransmission queue; for a retransmission message, the message identification bit is coded to be 1, the server receives and identifies a retransmission message request, firstly judges whether the request is received for the first time, if not, the request response is directly taken out from the buffer, and the message identification bit is coded to be 1 and sent to the client;
step four, aiming at long connection, starting heartbeat detection, adopting a mechanism of link reading idle and heartbeat detection, wherein the link reading idle means that no information is read by the link duration time T; when no new request arrives in the connection within the time M, the connection is actively closed, and resources are released; when the channel quality is detected to be reduced to a preset threshold value, the heartbeat detection failure frequency or the service request failure frequency reaches a preset value, the current long connection is closed, and the short connection mode is used for communication; and aiming at the short connection, when the channel quality is detected to be improved to a preset threshold value, the long connection is tried to be established with the server side, and the communication is carried out in a long connection mode.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011146265.4A CN112363849B (en) | 2020-10-23 | 2020-10-23 | Lightweight service interaction protocol method in tactical environment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011146265.4A CN112363849B (en) | 2020-10-23 | 2020-10-23 | Lightweight service interaction protocol method in tactical environment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112363849A true CN112363849A (en) | 2021-02-12 |
| CN112363849B CN112363849B (en) | 2022-11-11 |
Family
ID=74511874
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011146265.4A Active CN112363849B (en) | 2020-10-23 | 2020-10-23 | Lightweight service interaction protocol method in tactical environment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112363849B (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113141308A (en) * | 2021-06-21 | 2021-07-20 | 之江实验室 | Lightweight wired Mesh networking design method |
| CN113452759A (en) * | 2021-06-07 | 2021-09-28 | 武汉市多比特信息科技有限公司 | Method and device for sending and receiving websocket communication message |
| CN113595980A (en) * | 2021-06-25 | 2021-11-02 | 杭州天宽科技有限公司 | Configuration method based on TCP communication custom protocol |
| CN113609992A (en) * | 2021-08-06 | 2021-11-05 | 浙江大学 | Analysis method of shooting type sports tactical flow |
| CN114780480A (en) * | 2022-06-20 | 2022-07-22 | 龙旗电子(惠州)有限公司 | Data transmission method, device and equipment |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8090856B1 (en) * | 2000-01-31 | 2012-01-03 | Telecommunication Systems, Inc. | Intelligent messaging network server interconnection |
| CN103957241A (en) * | 2014-04-16 | 2014-07-30 | 中国工商银行股份有限公司 | Communication method and device based on message data |
| CN104796387A (en) * | 2014-01-21 | 2015-07-22 | 腾讯科技（深圳）有限公司 | Communication method and device of long connection of network |
| CN105550051A (en) * | 2015-12-25 | 2016-05-04 | 北京奇虎科技有限公司 | Asynchronous processing method and device of business request |
| CN106484713A (en) * | 2015-08-27 | 2017-03-08 | 中国石油化工股份有限公司 | A kind of based on service-oriented Distributed Request Processing system |
| CN109462634A (en) * | 2018-09-25 | 2019-03-12 | 郑州云海信息技术有限公司 | Message treatment method, device and equipment in a kind of distributed system |
| CN109831474A (en) * | 2018-11-26 | 2019-05-31 | 阿里巴巴集团控股有限公司 | Keep-alive system, method, server and the readable storage medium storing program for executing of http long connection |
| CN111225010A (en) * | 2018-11-27 | 2020-06-02 | 北京京东尚科信息技术有限公司 | Data processing method, data processing system and device |
| CN111669717A (en) * | 2020-05-08 | 2020-09-15 | 广州微算互联信息技术有限公司 | Cloud mobile phone data sending method, computer device and storage medium |
-
2020
- 2020-10-23 CN CN202011146265.4A patent/CN112363849B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8090856B1 (en) * | 2000-01-31 | 2012-01-03 | Telecommunication Systems, Inc. | Intelligent messaging network server interconnection |
| CN104796387A (en) * | 2014-01-21 | 2015-07-22 | 腾讯科技（深圳）有限公司 | Communication method and device of long connection of network |
| CN103957241A (en) * | 2014-04-16 | 2014-07-30 | 中国工商银行股份有限公司 | Communication method and device based on message data |
| CN106484713A (en) * | 2015-08-27 | 2017-03-08 | 中国石油化工股份有限公司 | A kind of based on service-oriented Distributed Request Processing system |
| CN105550051A (en) * | 2015-12-25 | 2016-05-04 | 北京奇虎科技有限公司 | Asynchronous processing method and device of business request |
| CN109462634A (en) * | 2018-09-25 | 2019-03-12 | 郑州云海信息技术有限公司 | Message treatment method, device and equipment in a kind of distributed system |
| CN109831474A (en) * | 2018-11-26 | 2019-05-31 | 阿里巴巴集团控股有限公司 | Keep-alive system, method, server and the readable storage medium storing program for executing of http long connection |
| CN111225010A (en) * | 2018-11-27 | 2020-06-02 | 北京京东尚科信息技术有限公司 | Data processing method, data processing system and device |
| CN111669717A (en) * | 2020-05-08 | 2020-09-15 | 广州微算互联信息技术有限公司 | Cloud mobile phone data sending method, computer device and storage medium |
Non-Patent Citations (5)
| Title |
|---|
| CODINGSIR: "基于netty的心跳检测", 《HTTPS://BLOG.CSDN.NET/EDUCAST/ARTICLE/DETAILS/47706863》 * |
| M SAIFUR RAHMAN 等: "Using adaptive heartbeat rate on long-lived TCP connections", 《2016 INTERNATIONAL CONFERENCE ON NETWORKING SYSTEMS AND SECURITY (NSYSS)》 * |
| 程序诗人: "微言Netty：分布式服务框架", 《HTTPS://WWW.CNBLOGS.COM/SCY251147/P/10983814.HTML》 * |
| 苏锦: "基于Netty的高性能RPC服务器的研究与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》 * |
| 陈艳军 等: "基于Socket 长短连接切换的C/S 模型设计", 《电脑知识与技术》 * |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113452759A (en) * | 2021-06-07 | 2021-09-28 | 武汉市多比特信息科技有限公司 | Method and device for sending and receiving websocket communication message |
| CN113141308A (en) * | 2021-06-21 | 2021-07-20 | 之江实验室 | Lightweight wired Mesh networking design method |
| CN113141308B (en) * | 2021-06-21 | 2021-09-14 | 之江实验室 | Lightweight wired Mesh networking design method |
| WO2022096019A1 (en) * | 2021-06-21 | 2022-05-12 | 之江实验室 | Lightweight wired mesh networking design method |
| CN113595980A (en) * | 2021-06-25 | 2021-11-02 | 杭州天宽科技有限公司 | Configuration method based on TCP communication custom protocol |
| CN113595980B (en) * | 2021-06-25 | 2023-05-23 | 杭州天宽科技有限公司 | Configuration method based on TCP communication custom protocol |
| CN113609992A (en) * | 2021-08-06 | 2021-11-05 | 浙江大学 | Analysis method of shooting type sports tactical flow |
| CN113609992B (en) * | 2021-08-06 | 2023-11-14 | 浙江大学 | Analysis method of clapping motion tactical flow |
| CN114780480A (en) * | 2022-06-20 | 2022-07-22 | 龙旗电子(惠州)有限公司 | Data transmission method, device and equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112363849B (en) | 2022-11-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112363849B (en) | Lightweight service interaction protocol method in tactical environment | |
| JP3902235B2 (en) | Data compression in data connection | |
| CN1494296B (en) | Defining network path transmission unit | |
| KR100334788B1 (en) | Method and apparatus for connecting a node to a wireless network using standard protocols | |
| EP1271886A2 (en) | Packet header compression | |
| US20040022222A1 (en) | Wireless metropolitan area network system and method | |
| US20020196743A1 (en) | Apparatus and method for enhancing performance in a packet data system | |
| US8116782B2 (en) | Communication quality control system | |
| WO2001028180A3 (en) | Method and system for compressing and decompressing packet headers | |
| Herrero | Dynamic CoAP mode control in real time wireless IoT networks | |
| KR20080106825A (en) | The method of mac layer header generation and data transmitting in mobile communication system | |
| CN112436994B (en) | Data transmission method and electronic equipment | |
| CN101304302A (en) | Method and system for transmitting video data | |
| CN111629331B (en) | Data transmission method in Internet of things | |
| CN111131179B (en) | Service processing method, device, network equipment and storage medium | |
| CN111371887A (en) | Internet of things log transmission method, client, server, equipment and storage medium | |
| CN113573337A (en) | Data sending method in industrial Internet of things | |
| US20050086383A1 (en) | Optimizing the compression efficiency in a packet data communication | |
| CN112468513B (en) | Terminal management communication method for enterprise network | |
| WO2020195878A1 (en) | Communication control device and method, and wireless communication device and method | |
| CN112583829A (en) | Method and device for self-adaptive multi-level end-to-end transmission of market information stream | |
| CN112272081B (en) | Full-duplex stateful communication protocol method for communication between robot and server | |
| US20040210559A1 (en) | Method for control of data compression | |
| US20020058474A1 (en) | Global sequence numbers in wireless communications systems and methods | |
| US6704306B1 (en) | Voice message service method for multimedia internet protocol system |
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 |