Re^2: Control TCP_MAXSEG (OS buffering) on Win32

OK, well to rephrase the requirement:

I have a 20KB/min (!) connection and the OS is currently buffering 3-4 mins worth of data, so I need to find a way to crank down the amount of buffering between the two apps, ie all I can do is affect the advertised receive window of the server socket which the remove app connects to (over localhost)

Given a set of machines running XP and Vista can anyone think of a way to control advertised receive window?

Curiously under Vista it seems that setting SO_RCVBUF controls the advertised window nicely - however, it looks like something wierd like 40KB ish + SO+RCVBUF on XP... (Need to repeat that test to remind myself of the magic number, however, I think it *wasn't* 64KB which would have been the obvious answer...)

I can post some test code if it's useful?

Comment on Re^2: Control TCP_MAXSEG (OS buffering) on Win32

Replies are listed 'Best First'.
Re^3: Control TCP_MAXSEG (OS buffering) on Win32 by Anonymous Monk on Nov 09, 2007 at 03:45 UTC
20KB/min? hmmm... for very slow connections, sometimes UDP would be a better option.	[reply]
Re^4: Control TCP_MAXSEG (OS buffering) on Win32 by TheWildgoose (Initiate) on Nov 09, 2007 at 16:53 UTC
Your point is fair, but in reality I can't see that it buys me much here. I'm proxying a TCP stream, so I need it reliable, so all I end up doing is re-implementing TCP on top of UDP... It would be possible to avoid the TCP backoff problems due to packet errors (not the same as congestion if you see the point), however, some simple benchmarks suggest that there isn't much to gain here... TCCP looks interesting mind! However, I need this thing cross platform and stable... Right now we use lots of compression and multiplexing of connection and even carefully limiting packet size to squeeze absolutely everything out of the link. My remaining issue is to control the OS buffering on the source side. Remember that I don't have control over the sender that I am buffering, so I need to indirectly affect their send speed - I really need to try and drop down the size of the OS buffers here - right now 64KB is a buffer of 3 mins or so! Any suggestions please...?!!	[reply]
Re^5: Control TCP_MAXSEG (OS buffering) on Win32 by BrowserUk (Patriarch) on Nov 09, 2007 at 17:20 UTC
You are speculating that changing the advertised MSS would affect the sender buffering, but that AS perl doesn't support it. Have you actually tried this from some other OS that does support it? You've said that you cannot change the sender, but then you've just given (fair) consideration to the idea of using UDP. Wouldn't that have required changes to the sender anyway? The very low transmition speed suggests that the sender is either very far away, or using a very low power transmitter? A little more information about the hardware/software setup might bring further possibilities to light. I am always amazed by the breadth of the backgrounds of the guys that frequent this place. It's just possible that with a more high level description of the problem, rather than questions of how to implement one possible solution, you would engage the interest of someone with experience in the field. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]