Summary of recent experience in socket programming

A small project I have been working on recently is not very difficult, but the network transmission part took a bit of trouble. Here is a summary of some recent experiences and lessons. Because it is my own experience, if there are any omissions, I will add corrections later.

The program uses the TCP protocol for transmission, first epoll_wait (in fact, there are not many connections, just familiarize yourself with it, and I did learn something), and then receive it. Because TCP has flow control, it will fragment large streams, so one recv cannot receive all the data. At the beginning, it first receives a header, which includes the length of the stream, and then calls recv to receive the entire data packet in a loop. Later, I felt that this was too cumbersome and low-level (and often received errors), so I thought about how to receive all the data at one time.

Referring to the code in the project, calling recvfrom can receive it once without sending a header first, and this function can be used for TCP and UDP. Immediately I felt that this was an artifact. I tried it, but there would still be incomplete reception. After thinking about it for a while, the project is UDP and will not perform "fragmentation". As long as you fill in a maximum value for the length, and the maximum buffer of the system is set to a larger size, and I am now a TCP, it will inevitably fragment, So the result is different.

So it returns to recv. Check the description of the recv function. There is an option MSG_WAITALL in the flag, which can ensure complete reception, but in this case, the length of the data packet must be known in advance. For the time being, a larger value is filled, and the insufficient data padding is supplemented, which is a bit wasteful. Later, I thought about going back to the original way, sending a header first, and then receiving it with MSG_WAITALL. However, according to the initial experience, if you receive multiple times, you will occasionally receive wrong data packets. I don’t know if it was not handled well at that time, and the reception was not complete, resulting in the readable signal not being eliminated. You have to verify it.

Postscript: I verified it today and there is no problem. And verified the EPOLLONESHOT option of epoll, there is no problem. There is a strange thing. Once again, I received a lot of wrong header information. After modifying the socket to non-blocking, it was normal, but the problem could not be reproduced later, which was very puzzling.

Looking at the code in the project, I also send a header (including length and flag) first, and then receive it. However, they call classes such as reactor in ace, so the code is relatively concise.

I have been in touch with Linux for many years, but I am embarrassed by such a low-level problem. . . . .

(fill in the code later)