Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TCP receive window size bound or limit - TCP_WINDOW_CLAMP option? - SO_RCVBUF doesnt change tcp window

621 views
Skip to first unread message

Stephan Hesse

unread,
Jan 28, 2011, 2:19:59 PM1/28/11
to
Hello,

I am experimenting in wireless ip communication.

For a TCP application i need to lower the TCP receive window.

The advertised window set by the windows tcp implementation is too big
and the wireless
link is therby flooded by incoming tcp packetsfrom servers behind it.

Of course, I could use the registry. But i want my application to be
able
to change the receive window size when it connects to the server
because
it has to adpat to the wireless physical link state ( i.e delay &
avalaible bandwidth)

Of course i use the setsockopt function with the SOL_RCVBUF parameter.
Of course i call it BEFORE connect() ( i actualy am using Boost and
getting the
socket handle from the tcp::socket.native() function but that has no
importance here,
as the boost socket functions on windows are mostly an OO-mapping and
handling
of winsock functions and handlers).

So, of course, it doesnt work.

When i set the rcvbuf to be say 12500 bytes, and then read
the value with getsockopt, it says 12500. Great.

Of course, the expected effect (slowing down connection speed), is not
happening.
Furthermore, when I use WireShark to look at the window size
advertised
in the ACK packets, it gives me values that are of course higher and
have never
anything to do with what it set.

I am aware that as I dont go above any default value but want to lower
the window,
winsock might ignore my request. In UNIX environment, there is a
special
socket option right for my purpose. Its called TCP_WINDOW_CLAMP and
it
limits the TCP receive window to a given amount for a given socket.

How can this functionality be realised in windows.

And yes, I am currently working with WinXP SP2. But I might be
interested
in solution for Windows 7, in case they differ, of course.

Cheers,
Stephan

Stephan Hesse

unread,
Jan 28, 2011, 2:23:30 PM1/28/11
to
I just would like to add that I use the same code on a Ubuntu/Linux
machine, also adding the TCP_WINDOW_CLAMP option,
and the desired functionality is obtained.

So this is not a code issue, i.e my code works.

Its more a request on functionality.

Maybe I have to do it differently on a windows machine.

Maybe its a windows tcp design issue.

I dont know and would be delighted to get some answers :)

Thanx in advance*

Stephan

0 new messages