TCP Connect &Windowsize

[ds34]

Folks,

I am doing a TL1 parser over TCP/IP and the my counterpart box (sending the TL1 responses) is using a fixed small TCP window size (fixed value of 512, no window scaling)

When sending large amount of data, my parser cannot handle the data in realtime, so the TCP receive buffer fills up and my winXP TCP stack will start to react with the TCP flowCTL to throttle the remote sender (setting a smaller window size and upon buffer is free again back to max 65k value) autonomously.

This action seems to hang up the remote box TCP stack and pause the TCP connection for about 15mins(so actually this seems to be a bug in the remote box)!

Ssince i do a port of an exisiting SOLARIS program I made the same tests using the SOLARIS TCP stack and there the problem is less frequent - since also the default receive window is much smaller...

So I am wondering whether it is somehow possible to tell the TCPConnect to use a smaller max TCP window size? Any DLL call ect? Maybe create a virtual interface ect?

I cannot set the complete windows TCP stack to this small window size, since other background applications really need the big window size to accomodate the high latency links.

I would be gratefull for any hint!

Daniel

[Glyph]

Silly window syndrome!

I believe there is a wiki on how to fix this.

Maybe I don't understand what you mean.

But, it sounds like all you need is fragmentation for your tcp sends?

Just create a function to trim the string down from what you've sent, to what you have not.

And, form there, have it adjusted by variable size through a function with tcpsend.

So it sends in smaller packages to the buffer, on the server side.

func send($size)

tcpsend($socket,stringtrimleft($string,$size))

$string &=stringtrimleft($string,$size)

endfunc

From wikipedia.org:

Solution

When the Silly Window Syndrome is created by the sender, Nagle's solution is used. Nagle's solution requires that the sender sends the first segment even if it is a small one, then the sender waits until an ACK is received or a maximum sized segment is accumulated.

When the Silly Window Syndrome is created by the receiver, David D Clark's solution is used. Clark's solution closes the window until another segment can be received or the buffer is half empty.

Hope that helps!

Edited November 18, 2008 by Glyph

[ds34]

Silly window syndrome!

So it sends in smaller packages to the buffer, on the server side.

thanks, but your proposal would fix it on the senders site - which is the (buggy) TL1 box - so it is out of my hands. At the moment that I have the problem, I was not sending for minutes (I was sending a command which creates a big data reply, i.e. a 10Mbyte logfile).

So the TCP flowCTL is purely happening in the Windows TCP stack - without my AutoIT appplication interaction. From wireshark I can see that the last proper data reply TCP fragement was sent to me BEFORE my Windows TCP stack made the window update....

Obviously the long data sequences causes the TL1 box stack to be confused, so it's dta->TCP stack function gets locked). So unfortunatelly there is nothing on the receiver to get this unlocked at the sender...

In order to throttle the sender earlier, I would like to set my local TCP window size to 512 for a single TCP connection...

thanks!

Daniel

Edited November 18, 2008 by ds34