TCP is a stream of bytes, not packets. You need to do your own framing at the application layer. A simple way to do that would be netstrings: https://en.wikipedia.org/wiki/Netstring

After multiple tests, using the event mechanism in conjunction with a loop can complete the data read. If the bufferevent mechanism is used in the loop, it may not be possible to read the data in the future. If the loop is not used, a random read event will be triggered Do you know if libuv has such a problem?

Sorry, I have no idea what you mean.

Sorry, I have no idea what you mean.

at present, I am going to give up using libevent because of this problem, and I want to choose another library to introduce into my own project. I just want to know if there is the same problem before using it, so I want to ask users who have used it.

It's not a library problem, your understanding is flawed.

libuv will exhibit the same behavior.

If your protocol requires that you proces content in some units you need to do the separation at the application layer.

without using any library, using the while loop recv or poll model can receive the data packet completely, even using the libevent library without a buffer normal event can ensure that the data can be received completely, similar to your connection given. The packet header itself contains the size of the entire packet, so it is not impossible to determine the packet boundary problem. The only problem with bufferevent_read is that bufferevent_read() can only get the data once when the ev_read event is triggered and the second time it gets the data is empty, and it can only wait until the ev_read event is triggered again, but the processing logic changes.

That's it, I think I know the answer, thank you!