Communication Programming PC software implementation (socket) -- first

I have registered a blog Park for a long time, but I only recently started to pay attention to it. I have missed many learning opportunities.

For the first time, I wrote a blog in the garden. If you have any inappropriate, unreasonable, or incorrect content, please click here ~.

 

Some time ago, I made a socket underlying communication project, using the TCP protocol, using the upper computer as the client, and the lower computer as the server. Many problems were encountered during the process, such as Asynchronous sending, receiving, multithreading, and timeout retransmission. Here, I will take this project out, encapsulate all the processes of the project, the knowledge involved, and the commonly used data processing methods in communication (packaged as DLL), and write them out and share them with you, if any, please correct me.

 

I. TCP protocol

 

I believe that communication is no stranger to TCP and UDP. The main difference between the two is that TCP is connection-oriented and UDP is connectionless; TCP is reliable data transmission, and there are three handshakes to ensure data reliability. UDP is unreliable transmission; TCP transmission speed is slower than UDP.

Specifically, TCP packets and so on are involved. I am a newbie and don't know much about it. Let's talk about it for prawns and Daniel. Of course, there is also a lot of knowledge on the Internet ~.

The reason for choosing the TCP protocol is that our instruments detect high risks. Therefore, we must ensure the correctness and reliability of the transmission commands.

 

Ii. Protocol format

 

Request data Command Format (sent by PC)

ID number (1 byte) + packet length (1 byte) + command word (1 byte) + command serial number (1 byte) + specific command (can be 0 byte, specific content, determined by the upper and lower computers) + Verification Code (1 byte)

 

Note:

1. The identifier (1 byte) is only an identifier of the hardware. It is generally identified by 0xfn, where n is between 1 and F. Of course, the identifier can be extended. If there are many instruments, the identifier starts from 0 x en.
2. The command package length (1 byte) is the length of all data from the identifier to the final verification code.
3. Command (1 byte) indicates the current communication command, for example, 0xc1 mark Setting Parameter command.
4. The command serial number (1 byte) is an identifier of the time sequence of the data packet. The decimal range is 1-255. When the value exceeds 255, the remainder of 256 is obtained. If the remainder is 0, the command serial number is set to 1, increasing from 1.
5. The specific command is not mentioned, that is, the core of the data packet. The status and other information required by the lower computer are included here. I will give an example later.
6. The verification code (1 byte), which is determined as follows: All the bytes except the Verification Code itself in the entire command are different or. It was originally intended to use the entire command, except for the verification code, all the bytes outside the province are added to obtain the last byte of the result, regardless of whether the overflow or not. However, the addition is no different or fast, and considering that the addition is easy to overflow, this method of obtaining the verification code is abandoned.

 

Data sending Command Format (sent by the lower computer)

ID number (1 byte) + packet length (1 byte) + command word (1 byte) + command serial number (1 byte) + instrument status (1 byte) + specific commands (which can be 0 bytes, specific content, determined by the upper and lower computers) + Verification Code (1 byte)

 

Note: The instrument status (1 byte) indicates whether the current instrument is working properly and whether there is any fault information. Command words and command serial numbers are directly copied from the received host computer commands without changing them. For other instructions, refer to the request data commands.

 

The above is a pure protocol, which is a protocol before network transmission encapsulation. During the packet transmission process, the transmission layer and the network layer will add information to it, which is a matter of network transmission.

 

Iii. Host Machine timeout and resend

 

The upper computer sends a command to the lower computer. After receiving the command, the lower computer returns the corresponding information, in one second, the host computer fails to receive the response information or does not receive the expected response information (format error, command word error, command serial number error, or incomplete data packet length ), in this case, the message communication process fails.

After the communication fails, the host computer resends the command (the command word and command serial number remain unchanged). If the communication fails three times in a row, the communication fails, the communication is terminated, and a prompt message is displayed.

 

Iv. Lower computer timeout and resend

 

During the measurement process, if the lower computer fails to receive any commands sent by the upper computer within 3 seconds, the communication fails and the power of the instrument is disabled.

 

5. Heartbeat packet Detection

 

In view of the fact that the host computer sometimes needs to wait for some user operations to send commands to the lower computer, in this case, add the heartbeat packet in the Protocol. The role of this function is to prevent the communication process from being interrupted due to the transmission delay of some commands on the host computer (such as waiting for receiving user input.

The heartbeat packet is sent once every 1 second. During normal communication, the upper computer needs to perform some operations or wait for user operations, so that the communication is idle. At this time, the upper computer sends commands to the lower computer.