TCP / IP: what to do if the Internet is lost while the server is reading a packet from the client?

Question

Computer networks

TCP / IP: what to do if the Internet is lost while the server is reading a packet from the client?
The situation is as simple as 3 kopecks.
Client code:

...
var bytes = new byte[30000000];
...
server.Write(bytes, 0, bytes.Length); //шлём пакет серверу
...

Server code:

...
var client = listener.AcceptTcpClient();
...
var bytes = new byte[30000000];
client.Read(bytes, 0, bytes.Length); //читаем пакет от клиента
...

And now, if the network simply disappears on the client, and even then, when the client starts writing a packet, and the server starts reading, then no exception will be thrown either on the client or on the server, and the server’s bytes array will be underfilled, from which - then the places in the array will be zero, that is, the package is damaged, and the server will quietly continue to work, try to process this array (parse JSON), and crash.
And, even worse: the same thing (probably) will happen to the client, if on the contrary the client starts reading the response from the server, and at that moment the connection is lost.
How to solve the problem?
It is necessary from the transmitting side (client) to somehow find out that the server received something wrong, and send it again in the hope that this time the transfer will be successful, and so on in a circle in an endless loop with a delay.
But, probably, you can’t just find out if the data was transferred to the server. Nothing better comes to mind than to make the server process such corrupted packets and return a response to the client with success or error, but then you will have to make a response for each packet ... And one more thing: what if the packet with the response turns out to be damaged?)) This means that the client must also give an answer to this answer ... And if this answer is also damaged, and if the next, and if the next, a vicious circle of answers ...
And I also have keep-alives, custom implementation ... What will happen to them in this case, and is it possible to somehow use them for this check ...
In short, I got confused. This bearded TCP is a real mind blowout. You don't wish it on your enemy.
PS
Of course, in fact, my packet sizes are not so huge, I deliberately took an almost extremely large size, for the convenience of simulating a disconnection (I pull out the network cable from the computer).
But whether the packet is at least 2 bytes, anyway - there is a possibility, and it must be taken into account.

Answer 1

First, let's separate the flies from the cutlets. Packets in TCP, you have a buffer.
Second, TCP guarantees that the packet will be delivered (in the order you specify when sending it). Until the packet is transmitted in its entirety, the TCP/IP stack will repeat it. The algorithm of the protocol is as follows. However, there are circumstances stronger than TCP (disappearance of a connection from this series) and any program must take into account the fact that the data may not reach or reach incompletely.
Thirdly, if not all the data you are waiting for came to the buffer, then you either need to transfer the checksum (what to do if it didn’t [all] come?), or, more correctly, transfer not a flat buffer, but some a data structure where you can check that the field values ​​have changed (they were filled when receiving data) compared to the initial values. And proceeding from this, decide that the entire structure has arrived (the last field, for example, is the checksum, by default - 0) or it must be requested again.
And how did you want? It's like a fairytale? You can write like in a fairy tale if your program works 101% only and exclusively on the local network . In this case, the disconnection of a connection or segment is an emergency and it is not for you to fix it.

Answer 2

In general, I fully support Smithson and Oleg Tsilyurik
Check error codes returned by transmit/receive methods. When working with a network, you should always take into account that the transmission or reception will fail or not all data will be received / transmitted.
Those. in fact, you should write a program based on the fact that receiving / transmitting errors are not only possible, but they will definitely always be.
And yes, custom keep-alives for TCP are complete bullshit - everything is already implemented in the protocol.

Answer 3

It is necessary either to write the message number and size when sending. Since this is TCP, the client will send odd numbers, receive even numbers, the server will receive odd numbers, and send even numbers. If suddenly there is a gap or something else - we are waiting for our package. If the package is missed, please send your number. That is, it is also necessary to implement peculiar service requests.
Usually use already ready NetworkManager'y.

Answer 4

In short, I'm confused. This bearded TCP is a real mind blowout. You don't wish it on your enemy.

Yeah...
... especially when you don’t understand that TCP is a streaming protocol for reliable transmission, that there (from the point of view of the code, socket) there are no and cannot be any packets , and you start inventing your own vision of reality and building cycles from keep-alives to "custom implementation"... ;-)
Take W. Stevens' books on TCP / IP and network application development, and read, read, read ... until enlightenment.

Answer 5

If I understand the problem correctly, then either do Heartbeat (a fashionable name for a bicycle) or wait until the server timeouts after an indefinite period (well, an hour there).
Classics of the genre on this link. Read the "how not to" section carefully.
Detection of Half-Open (Dropped) Connections