CN117082125A - Data exchange method based on TCP/IP protocol and peer communication program - Google Patents

Data exchange method based on TCP/IP protocol and peer communication program Download PDF

Info

Publication number
CN117082125A
CN117082125A CN202310946083.2A CN202310946083A CN117082125A CN 117082125 A CN117082125 A CN 117082125A CN 202310946083 A CN202310946083 A CN 202310946083A CN 117082125 A CN117082125 A CN 117082125A
Authority
CN
China
Prior art keywords
message
loop
receiving
server
thread
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
Application number
CN202310946083.2A
Other languages
Chinese (zh)
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.)
Hunan Ruiling Technology Co ltd
Original Assignee
Hunan Ruiling Technology 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 Hunan Ruiling Technology Co ltd filed Critical Hunan Ruiling Technology Co ltd
Priority to CN202310946083.2A priority Critical patent/CN117082125A/en
Publication of CN117082125A publication Critical patent/CN117082125A/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)

Abstract

A data exchange method based on TCP/IP protocol and peer communication program, using communication middleware, two peers communicating can establish several loops for transmitting message; the communication transmission mode is divided into a static link and a dynamic link; the two peer ends are divided into a client end and a server end, and when the connection is established, the client end is responsible for sending a common message and a heartbeat message to the server end by utilizing a communication loop, and simultaneously, a thread responsible for receiving a reply message and a thread responsible for receiving the heartbeat message are started; the server terminal is responsible for starting a thread responsible for receiving a common message and a thread responsible for receiving a heartbeat message, and sending a confirmation message and the heartbeat message to the client terminal by utilizing a communication loop. The invention can utilize the Internet to carry out remote instant communication between a plurality of terminals on the network through synchronous communication, and can utilize the communication data carrier to realize data interaction or instruction execution between the hosts, thereby realizing the interconnection between systems.

Description

Data exchange method based on TCP/IP protocol and peer communication program
Technical Field
The invention belongs to the technical field of communication, and relates to a data exchange and exchange method and system based on a TCP/IP protocol and a peer-to-peer communication program.
Background
With the development of modern computer technology, the traditional manufacturing industry is realizing digital upgrades. The traditional manufacturing industry is a huge system, comprises a large number of production systems and management systems, and is responsible for realizing a plurality of complex functions such as process management, production management, personnel management and the like. The systems are not isolated from each other, but rather have strong coupling. The high-efficiency management of enterprises can be realized only by integrating the systems mutually, opening the gap between the systems and enabling the systems to coordinate with each other in the production process. Information transfer technology, in which the "tie" function between the various systems is implemented, is the most critical component. How to quickly and accurately transfer information between systems is a main defect of the existing communication mode, and once the situation of mistransmission or disconnection occurs, the method has great influence on work production.
Disclosure of Invention
The invention aims to solve the problems in the prior art, and provides a data exchange method based on a TCP/IP protocol and a peer-to-peer communication program, which can realize data exchange between two ends by configuration and realize interconnection between various systems in manufacturing industry.
The technical aim of the invention is realized by the following technical scheme:
a data exchange method based on TCP/IP protocol and peer communication program, comprising the steps of:
1) The mutual communication of the peers adopts a mode based on a communication middleware, and by utilizing the communication middleware, two communicating peers establish a plurality of loop wires for transmitting the message, wherein the two peers are divided into a client end and a server end;
2) When connection is established, the client end is responsible for sending a common message and a heartbeat message to the server end by utilizing a communication loop, and simultaneously starting a thread responsible for receiving the reply message and a thread responsible for receiving the heartbeat message; the server end is responsible for starting a thread responsible for receiving a common message and a thread responsible for receiving a heartbeat message, and sending a confirmation message and the heartbeat message to the client end by utilizing a communication loop;
3) The client end and the server end need to intermittently send heartbeat messages to the opposite end, and if the heartbeat messages are successfully sent, the transmission link under the static link is smooth, and the heartbeat states of the client end and the server end are refreshed; if the heartbeat message is failed to be sent, the problem of the transmission link is indicated, the current loop needs to be disconnected, the resources are released, and a new loop is re-tried to be established.
In one embodiment, after the client communication loop is started, whether the transmission link is smooth is detected by using a heartbeat message, when the transmission link is not smooth, connection between the loop and the server is started first, and after connection is completed, a heartbeat monitoring thread is started again, so that automatic reconnection of the loop can be realized when the loop is abnormally broken.
In one embodiment, after the communication loop of the server end is started, whether the transmission link is smooth is detected by using a heartbeat message, when the transmission link is not smooth, connection between the loop and the client end is started first, and after connection is completed, a heartbeat monitoring thread is started again, so that automatic reconnection of the loop can be realized when the loop is abnormally broken.
In one embodiment, before sending a data message, the client first determines whether the transmission link is in a clear state; when the transmission link is in a smooth state, the message sending thread sends a data message to the server, and when the Socket transmission link is in an abnormal state, the loop is closed, the resource is released, and reconnection is attempted.
In one embodiment, after the server receives the thread of the message, the server receives the message information from the client. After the thread receiving the message receives the message information, judging the message type: when the message information is a heartbeat message, confirming that a transmission link is unblocked, and waiting for receiving new message information; when the message information is a data message, the data message is stored, a confirmation message is sent to the client, and then the receiving of new message information is waited.
In one embodiment, if the client starts a buffer type sending process, and after a thread receiving a message response is started, the client receives message response information from the server, and determines according to the response condition:
when receiving the message response information, the message sending thread discards the sent data message and sends the data message of the next round to the server;
when the message response information is not received within the timeout period and the retransmission times are not exceeded, the message sending thread resends the data message to the server;
and when the message response information is not received within the timeout period and the retransmission times are exceeded, closing the loop, releasing the resource and attempting to reconnect.
In one embodiment, if the client starts a sending process of a non-buffer type, and after a thread receiving a message response is started, the client receives message response information from the server, and determines according to the response condition: when receiving the message response information, the message sending thread sends the data message of the next round to the server; when the message response information is not received, the transmitted data message is immediately discarded.
The invention has the beneficial effects that: the method and the system realize accurate and rapid transmission of data in the industrial Internet, solve the problem of information transmission among various systems in the industrial manufacturing industry, realize mutual integration and coordination of the various systems and realize efficient management of enterprises.
Drawings
Fig. 1 is a schematic diagram of connection between a server and a client.
Fig. 2 is a schematic diagram of a return acknowledgment message.
Fig. 3 is a schematic diagram of sending a heartbeat message.
Fig. 4 is a communication handshake schematic.
Fig. 5 is a schematic diagram of a communication handshake with timeout monitoring.
FIG. 6 is a schematic diagram of a system exception condition with timeout monitoring.
Fig. 7 is a schematic diagram of retransmission functions.
Fig. 8 is a schematic diagram of a send unbuffer message.
Fig. 9 is a schematic diagram of a transmit buffer message.
Fig. 10 is a schematic diagram of a heartbeat message.
Fig. 11 is a schematic diagram of a heartbeat message timeout.
Detailed Description
The invention will be further described with reference to the drawings and detailed description.
Fig. 1 shows: the messages received and sent use two logical connections. The logical connections are also referred to as loop lines, each of which employs Server/Client mode. In the socket interface of TCP/IP, the Server/Client mode is very popular. The Server/Client mode determines how to establish a logical connection, but does not determine the communication protocol after establishing the connection. In the specifications, both the active party transmitting data and the passive party receiving data are determined in advance. The master is similar to the Client in the Server/Client mode, and the master always initiates the communication connection until the logical connection is established. The passive party is similar to the Server side in the Server/Client mode, and waits for a message from the active party until the communication connection is established, and sends an acknowledge message.
Fig. 2 shows: when a receiving process receives a normal message from another process, it must return an acknowledge message from the same loop session to the sender. The format of the confirmation message is shown in table 1.
Fig. 3 shows: after connection establishment, the heartbeat message is used for heartbeat confirmation between computers. The receiver of the heartbeat message does not send an acknowledgement message (ACK) back to the sender. In the static link mode, if no data message is sent all the time in a certain time interval, a heartbeat message needs to be sent to the opposite side to detect whether the communication link is smooth, and if the heartbeat message is failed to be sent, the static link has a problem. The format of the heartbeat message is shown in table 2.
When a communicating application sends a message, it cannot get any result from the network. Thus, we design that the receiver needs to return an acknowledge message to the sender after receiving the message and checking its validity, the process is shown in fig. 4. The transmitted data message needs to follow a prescribed data format, as shown in table 3.
Whether the message is successfully sent or not is judged according to whether the response message of the opposite party can be received or not. Thus, if a receiving process in a peer computer fails to reply to a sending process due to an exception condition, that sending process will always wait for an acknowledgment message. To avoid this, the sending process uses a timer for generating the timeout event.
When the sending process sends a generic message, it generates a timeout monitoring function. If the sending process receives the confirmation message in the overtime period, the sending process is successful, as shown in fig. 5; if the sending process does not receive an acknowledgment message within the timeout period, it will announce a transmission error management process, as shown in FIG. 6.
When the sending process sends a normal message, it will wait for an acknowledge message. If the sending process does not receive the confirmation message within the timeout period, it will retransmit a common message again. If the receiving process does not respond to the retransmitted message, the sending process may notify the transmission error management process. As shown in fig. 7.
The transmission process is divided into two types: one is a non-buffer type and the other is a buffer type.
The transmission flow of the non-buffer type includes (fig. 8):
(1) Sending a message;
(2) The message buffer type transmission is discarded immediately after the sending process does not receive the confirmation message from the peer computer.
The flow of buffer types includes (fig. 9):
(1) Sending the message to a sending queue;
(2) Sending a first message in a queue;
(3) When the sending process receives a reply acknowledge message (ACK) from the peer, the sending process will delete the message from OTQ;
(4) When the timeout monitor timer expires, the communication layer retains and resends the message;
(5) Other messages in the queue are not sent until a message is not deleted.
To notify the other party that the local computer is active, one computer periodically (T1 minutes) sends a heartbeat message to the other computer. The heartbeat message is sent out by the sending process through the outbound session, as shown in fig. 10; on the other hand, if the opposite computer does not receive the heartbeat message within T2 (t2=t1×2), it determines that the sending computer is not activated, and then actively disconnects from the opposite computer (the loop responsible for receiving the message is disconnected), as shown in fig. 11.
TABLE 1 format of text
。
TABLE 2 Heartbeat message format
。
Table 3 data formats of data messages transmitted
。

Claims (7)

1. A data exchange method based on TCP/IP protocol and peer communication program, characterized by comprising the steps of:
1) The mutual communication of the peers adopts a mode based on a communication middleware, and by utilizing the communication middleware, two communicating peers establish a plurality of loop wires for transmitting the message, wherein the two peers are divided into a client end and a server end;
2) When connection is established, the client end is responsible for sending a common message and a heartbeat message to the server end by utilizing a communication loop, and simultaneously starting a thread responsible for receiving the reply message and a thread responsible for receiving the heartbeat message; the server end is responsible for starting a thread responsible for receiving a common message and a thread responsible for receiving a heartbeat message, and sending a confirmation message and the heartbeat message to the client end by utilizing a communication loop;
3) The client end and the server end need to intermittently send heartbeat messages to the opposite end, and if the heartbeat messages are successfully sent, the transmission link under the static link is smooth, and the heartbeat states of the client end and the server end are refreshed; if the heartbeat message is failed to be sent, the problem of the transmission link is indicated, the current loop needs to be disconnected, the resources are released, and a new loop is re-tried to be established.
2. The data exchange method based on the TCP/IP protocol and the peer communication program according to claim 1, wherein: in the step 3), after the communication loop of the client is started, whether the transmission link is smooth or not is detected by using a heartbeat message, when the transmission link is not smooth, connection between the loop and the server is started first, and after connection is completed, a heartbeat monitoring thread is started, so that automatic reconnection of the loop can be realized when the loop is abnormally broken.
3. The data exchange method based on the TCP/IP protocol and the peer communication program according to claim 1, wherein in step 3), after the server communication loop is started, whether the transmission link is smooth is detected by using a heartbeat message, when the transmission link is not smooth, connection between the loop and the client is started first, after connection is completed, the heartbeat monitoring thread is started again, and automatic reconnection of the loop can be realized when the loop is abnormally disconnected.
4. A data exchange method based on TCP/IP protocol and peer communication procedure as claimed in claim 2, characterized in that: in step 2), before the client sends the data message, judging whether the transmission link is in a unobstructed state or not: when the transmission link is in a smooth state, the message sending thread sends a data message to the server; when the Socket transmission link is in an abnormal state, closing the loop, releasing the resource and attempting to reconnect.
5. The data exchange method based on the TCP/IP protocol and the peer communication program according to claim 4, wherein: in the step 2) and the step 3), after the server receives the thread of the message, the server receives the message information from the client, and after the thread receiving the message receives the message information, the message type is judged; when the message information is a heartbeat message, confirming that a transmission link is unblocked, and waiting for receiving new message information; when the message information is a data message, the data message is stored, a confirmation message is sent to the client, and then the receiving of new message information is waited.
6. The data exchange method based on the TCP/IP protocol and the peer communication program according to claim 5, wherein: in step 2), if the client starts a buffer type sending process and a thread receiving a message response is started, receiving message response information from the server, and judging according to the response condition:
when receiving the message response information, the message sending thread discards the sent data message and sends the data message of the next round to the server;
when the message response information is not received within the timeout period and the retransmission times are not exceeded, the message sending thread resends the data message to the server;
and when the message response information is not received within the timeout period and the retransmission times are exceeded, closing the loop, releasing the resource and attempting to reconnect.
7. The data exchange method based on the TCP/IP protocol and the peer communication program according to claim 5, wherein: in step 2), if the client starts a sending process of a non-buffer type, and after a thread receiving the message response is started, receiving message response information from the server, and judging according to the response condition: when receiving the message response information, the message sending thread sends the data message of the next round to the server; when the message response information is not received, the transmitted data message is immediately discarded.
CN202310946083.2A 2023-07-31 2023-07-31 Data exchange method based on TCP/IP protocol and peer communication program Pending CN117082125A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310946083.2A CN117082125A (en) 2023-07-31 2023-07-31 Data exchange method based on TCP/IP protocol and peer communication program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310946083.2A CN117082125A (en) 2023-07-31 2023-07-31 Data exchange method based on TCP/IP protocol and peer communication program

Publications (1)

Publication Number Publication Date
CN117082125A true CN117082125A (en) 2023-11-17

Family

ID=88716207

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310946083.2A Pending CN117082125A (en) 2023-07-31 2023-07-31 Data exchange method based on TCP/IP protocol and peer communication program

Country Status (1)

Country Link
CN (1) CN117082125A (en)

Similar Documents

Publication Publication Date Title
CN101699797B (en) Method for performing data transmission by using UDP protocol
JP5695558B2 (en) Method for enabling faster recovery of client applications in case of server failure
CN103036904A (en) Method of data reliable transmission with user datagram protocol (UDP) in communication network
CN105657646A (en) Bluetooth 4.0 based device-to-device big data communication method
RU2701523C1 (en) System and method of providing synchronization in transmissions in a mode without connection
US20070263626A1 (en) A System for Session-Oriented Reliable Multicast Transmission.
WO2021232681A1 (en) Communication method for earphone and charging box, charging box, earphone and readable storage medium
CN110493775B (en) Communication method and system adapted by ATT and exception handling
KR20100084118A (en) Method for improving a tcp data transmission process in case the physical transmission medium is disconnected
CN101262452A (en) Network connection control method and control device and routing device
CN107508916B (en) Server link management method for intelligent robot
CN117082125A (en) Data exchange method based on TCP/IP protocol and peer communication program
CN103607311A (en) System and method for reestablishing TCP connection seamlessly
CN113472810B (en) Method and system for SOCKET communication based on TCP/IP protocol
CN114125021B (en) Terminal information release system based on Netty message drive
CN112468513B (en) Terminal management communication method for enterprise network
CN101094241B (en) Transmission method and device of hybrid automatic requesting retransmission
JP3266199B2 (en) Reliable data transfer method
CN116488712B (en) Non-real-time relay communication method based on improved store-and-forward protocol
CN111417116B (en) Communication method and system adapted through ATT, read-write and exception handling
CN114629597B (en) Reliable transmission method and system applied to serial port
CN112153087B (en) Cross-Net communication method for third-party network terminal
KR100462870B1 (en) Method for Setting up Synchronization of Communication Exchange System
CN106789696B (en) Congestion control-based non-connection-oriented reliable redundant network transmission method
Howser et al. Flow Control

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