1
I was curious to know the size of the internal winsock read-buffer associated with a telnet socket. I wanted to know how long it would take to fill it on my internet connection, and I wanted to set my recv-buffer the same size so that a single recv would flush it.
Several Microsoft references stated that the default size was 8K. So I called getsockopt with parameters SOL_SOCKET, SO_RCVBUF to confirm this. It returned 1244364 bytes - over 1.2 MB!
I didn't trust either figure. I programmed a loop which did a blocking-recv on a remote telnet server, using a huge 2 MB buffer.. No matter how long I ran it for, the maximum size returned to each recv was 128K. recv would never return more than 128K bytes, even though it was passed a buffer-size of 2M.
I thought that this 128K might be an artefact of my internet-speed. So I had the program sleep for 20 secs after each recv. I thought that this would give the internal buffer plenty of time to fill up to its capacity. But the size returned to recv actually shrank - to exactly 74055 byte.
None of this makes a lot of sense to me. Is the "actual" internal buffer size 128K? Then what is getsockopt returning? And why does Sleep (and SleepEx) have such a bizarre effect? Surely Windows doesn't leave an internal buffer half-full just because the high level process is asleep.
Incidentally, I also tried changing the buffer-size using setsockopt. This function returned without error but had no effect on the buffer-size, regardless of its value, and regardless of whether a connection was open. A subsequent getsockopt always returned 12443644 bytes. I found a reference which stated that this is characteristic of some Windows Sockets implementations. So much for setsockopt.
I am using Microsoft C on XP Home, winsock2.h, wsock32.lib. My internet speed is 512 Kbps.
