Socket recv call freezes thread for approx. 5 seconds

Question

I've a client server architecture implemented in C++ with blocking sockets under Windows 7. Everything is running well up to a certain level of load. If there are a couple of clients (e.g. > 4) receiving or sending megabytes of data, sometimes the communication with one client freezes for approximately 5 seconds. All other clients are working as expected in that case.

The buffer size is 8192 bytes and logging on the server side reads as follows:

TimeStamp (s.ms) - received bytes

…

1299514524.618 - 8192

1299514524.618 - 8192

1299514524.618 - 0004

1299514529.641 - 8192

1299514529.641 - 3744

1299514529.641 - 1460

1299514529.641 - 1460

1299514529.641 - 8192

…

It seems that only 4 bytes can be read within that 5 seconds. Furthermore I found out that the freezing time is always arounds that 5 seconds - never 4 or less and never 6 or more...

Any ideas?

Best regards

Michael

Fawcette

Are all of these recv calls on the same thread or separate threads? Do you have any APCs being queued to the thread? – Winstonwinstonn

All these recv calls belong to the same thread. I'm using pthreads, but I have the same behavior if only one thread is used to collect the queries on server side. – Fawcette

I have the exact same problem. I found your post by searching Google for "winsock 5 seconds". I have a test program that exchange data with a local server (127.0.0.1) at full speed, and in both directions. What I found is that every few seconds, at random, recv() blocks for almost exactly 5 seconds (+- 1ms). During this time the CPU goes to idle, returning to 100% after the 5 seconds. So far I have not been able to find a solution. – Grubb

Answer 1

This is a Windows bug.

KB 2020447 - Socket communication using the loopback address will intermittently encounter a five second delay

A Hotfix is available in

KB 2861819 - Data transfer stops for five seconds in a Windows Socket-based application in Windows 7 and Windows Server 2008 R2

Barrault

Answer 2

I've had this problem in situations of high load: the last packet of TCP data sometimes reached before the second to last, as the default stack is not defined for package sorting, this disorder caused in receiving similar result to what you describe.

The solution adopted was: load distribution in more servers

Petrifaction