TCP recv timeout drop

[LunaRebirth]

Hello,

I'm implementing a download system using TCP.
When I send small or medium files, there are no issues.
However, when I send large files that could take up to 60 seconds for the final download packet to reach the client, it quits receiving the data after so long.

I believe that TCP is recognizing the time it takes for the final half-ish packets to be sent and then received is a rather long amount of time, and quits trying to receive them.
The server shows that all bytes of the file are being sent, but the client shows that recv quits trying to receive the bytes after a period of time.

Is there some way I can make TCP not do this timeout, but rather continuously send?
I'm assuming a flag like this would conflict with other timeout methods in TCP, such as determining a disconnection.

I am trying to stray away from an ID-system where if the ID is not the last ID + 1, then request the packet again (ensuring there is no loss, since it is waiting for each individual ID), but speed is a big factor and I need all the available bytes I can get.

Thanks

[CuteAlien]

setsockopt allows setting all kind of options. Like SO_RCVTIMEO which might be what you want. Thought it might be better to try and understand the code in some opensource network library to see how they solve it. I don't really think you should get a timeout from sockets for this as the packets for large files shouldn't travel longer than for small files. It rather sounds like a problem in using them to me, but it's probably been 2 decades since I wrote anything with sockets without a library in between... (no critic - I think it's a good way to understand tech to use it on lowest level once).

[LunaRebirth]

setsockopt allows setting all kind of options. Like SO_RCVTIMEO which might be what you want. Thought it might be better to try and understand the code in some opensource network library to see how they solve it. I don't really think you should get a timeout from sockets for this as the packets for large files shouldn't travel longer than for small files. It rather sounds like a problem in using them to me, but it's probably been 2 decades since I wrote anything with sockets without a library in between... (no critic - I think it's a good way to understand tech to use it on lowest level once).

Ah yes, I suppose it's worth mentioning that I'm using non-blocking sockets.
Thanks! I'll check it out

[CuteAlien]

How do you get a timeout exactly? Which function - which results? Usually timeout should be about blocking receive calls (so the function can quit at some point).

[LunaRebirth]

I'm only receiving WSAEWouldBlock, which seems like it's okay.
But if I watch a countdown, like "Trying to send %d more bytes", the server gets to 0, and then the client quits trying about half-way through.
If on the server, I add Sleep(100) before each send, the client is able to catch up recv to the server's send, and successfully receives the whole file.
So I suppose that's where my idea of "it must be a timeout" came from.
I've reviewed my code at least a dozen times, and did an output on each send to make sure the file really is sending, and the server is able to output the send()s to an identical file that should be sending.

[CuteAlien]

Do you check for all errors of recv?

[LunaRebirth]

Yes, and I'm checking that all data is being received per recv

[CuteAlien]

Hm, no more ideas (at least without seeing code - but I'll be away for a few days, so you probably figure it out anyway before I'm back).

[LunaRebirth]

Ah, I did figure it out. I thought doing send() in a while loop until all bytes were sent was sufficient enough.
After I checked if the send() got an error, then resend the same message, it worked..

noob mistake. thanks for your help