Proxomitron reduces RWIN to 32768

[laighleas]

JJoe Wrote:Rrrrrrrrrrats! No unaffected XP/Home/SP2 users.

OK mulled this over a bit more. I?m not an expert on this, but this is my take on it.

Firstly, it looks as if Scott was trying to set such a large value for the MTU in Proxomitron that the program was effectively invisible as far as the browser and the server were concerned. The limitations on traffic thus lay entirely with the operating system, the internet connection, and the server. Strikes me that Scott was doing this to avoid Proxomitron slowing down browsing. If the MTU of Proxomitron is greater than that used by the system, then Proxo would only use one connection, packets would go through the filters unfragmented, and (as far as the packets were concerned) Proxo had no effect on traffic except for filtering. Of course, keeping the packets intact would probably make filtering more efficient.

Hmm! I dimly recall, having once spoken to Scott in the past, that he said a few things which might imply that was his approach, but I can?t be sure. Just got this nagging feeling. :-( I?m going to have to rack my brain a lot ? and it was some years ago ? but I?ve a feeling that he did say something like that.

Anyway, XP has the capability for very large receive window sizes, though these don?t appear to be turned on by default. Large receive window sizes are unlikely to be of much use for dialup connections, give that the bottleneck is the modem and the telephone line, so the problem might not be apparent on a dialup connection, particularly since a lot of dialup software apparently sets the window size incorrectly (i.e. it doesn't optimize it).

OTOH, large RWINs come into their own in broadband. Now if Windows can send larger packets than Proxomitron can handle, the latter is going to have to fragment the packets. Proxomitron can compensate for this by opening up multiple connections; I?ve seen it open up more than thirty under sp1, and so far I?ve seen 15+ under sp2. The actual impact on observed browsing speed may therefore not be as high as the reduced RWIN might imply, as long as the server concerned accepts multiple connections. You can check how fast you?re surfing through this page: http://www.numion.com/ See if having Proxomitron connected makes any difference to the reported speed. It would be interesting to know if filtering fragmented packets makes any difference to speed, but that's rather beyond me.

Of course, if the server restricts the number of connections to two simultaneous connections (i.e. enforces the spec), and if Proxomitron is trying to open up more than ten connections, (i.e. has more than 10 half-open connections), then you sail straight into the problem with the unmodified sp2 stack, at which point things could start slowing down noticeably.

So you?ve got several factors: the use of XP and large windows, broadband connections, the problems with sp2?s tcpip.sys, and the fact that Proxomitron seems to have been optimised for dial-up connections. About the only way round this would be to increase the size of packets that Proxomitron can send and receive - RFC 1323 allows for receive windows of up to 1 Gb. However, since Scott is no longer around, that?s not possible. :-( Proxomitron can compensate by opening more connections, but to avoid problems there, you?ll need to patch tcpip.sys. Even then, you may occasionally run into servers that enforce the internet spec.

Does that make sense to anyone? Mind you, to confirm this, we?d probably need Kuruden?s input ? I?d think if anyone knew about the inner workings of Proxomitron as a program, he would.

That's my two penn'orth, unless someone can suggest anything else.

Kevin