Is it possible for the receiver to determine the "packet boundaries" of the sender's TCP?

Question

Computer networks

Colleagues, the question turned out to be crooked. I will clarify. Interested in an answer from experts who understand TCP / IP well.
As far as I understand, the MTU for Ethernet is about 1500 bytes. Accordingly, if I send fewer bytes to the socket, then they may linger in the buffer until the next (several) sends if there is no PSH flag. It's like that?
The recipient (let's take NodeJS as an example) will pull the callback to receive data into the socket for each of my "messages". For each of my individual parcels less than 1500 and equipped with PSH. And it can turn out so that the packet on the way is fragmented? And will it come in two TCP packets? And then I will get two callback calls?
Or, if I send more than 1500, then it definitely goes in several packets. Will it be multiple callbacks on the receiving side? Guaranteed as many as packages or unpredictable? Or can the polling cycle in the NodeJS event machine be superimposed on this, and there can be a different number of proofreadings and callbacks?
I try to throw 60K into the socket from one nodejs process to another and get 4 callback calls on the receiver. This seems to be less than the call for the package, but more than one call for the entire package.
Accordingly, there are two questions:
- Is the number of callbacks predictable?
- Is it possible to understand that these several TCP packets are one sending of the client? I saw some reassembled packages in the analyzer, but have not yet understood what it is about.
I ask the question because I want to know if I can receive on the receiver, as it were, the events "the client sent the package." And it doesn't matter how many TCP packets it is.
Or not? Or just a pipe from which the bytes fall in the correct order, but without any boundaries, or at least not corresponding to write operations to the socket from the sender.
If it's vague, I'll add it.

Answer 1

Scorpi and Pavel Kityan urgently need to start reading Sneijder's wonderful textbook - Efficient TCP / IP Programming
In short - you must send the length of the transmitted data before transmitting, then receive the pieces, sum their lengths and collect the total from them.
You should never get hung up on the fact that TCP internally cuts a stream of bytes into datagrams. For a TCP programmer - a pipe about two sockets, one - on the client, the second - on the server.