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

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...?!!

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]