Post Reply 
Proxomitron reduces RWIN to 32768
Nov. 04, 2005, 12:52 PM
Post: #61
 
Forgot to mention - the tests were conducted connecting through a firewall (ZoneAlarm), with a) Proxomitron enabled, connecting directly to the net b) Proxomitron filters bypassed, connecting directly to the net c) browser connecting directly to the net via the firewall. The OS is XP sp2 Home with .NET, connecting via BT Broadband. Tcpip.sys has been patched, as per previous post, and the stack hardened. I was using Active Ports to monitor connections, and Sidki's filters in Proxomitron, though with a couple of extra ones added.

Kevin
Add Thank You Quote this message in a reply
Nov. 04, 2005, 02:02 PM
Post: #62
 
Well, with a bit of tweaking I've got RWin up to 257004 under all circumstances, whether Proxomitron is used or not.

Kevin
Add Thank You Quote this message in a reply
Nov. 04, 2005, 03:17 PM
Post: #63
 
laighleas Wrote:
Kye-U Wrote:
Quote:Bet you both have SP2.
I have read that SP1 was OK.
Win98 is OK.
So Microsoft did it. ;-)

--
JJoe

Perhaps when a proxy server is used in SP2, the RWIN is limited?

Not impossible. In sp2 Microsoft limited tcpip.sys to handling only 10 incomplete connections at a time. This is the infamous "EventID 4226: TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts." The idea behind this was to slow down the speed at which worms spread. However, it has broken a few programs, including P2P programs.

Now I've just checked on opening a moderately simple web page, and Proxomitron was opening 4 connections. Won't take much to hit the limit. On some occasions I've seen it open far more - usually when I was using a proxy handler after Proxomitron - so it might, with some setups, fall foul of this limit, and in a few cases, badly so. Anything more than 10 will have to wait in a queue, slowing things down drastically, particularly if it's trying to open up 20+ connections, which I have seen. Fortunately there is an unofficial fix - patch tcp.ip.sys so that it can handle 50 incomplete connections at once, which was the original setting before sp2:

http://www.lvllord.de/?lang=en&url=tools

This works - I've run it on my machine. I tested my connection at http://www.dslreports.com/tweaks and got 65535, whether Proximitron was used, bypassed or not used at all. Gives no problems at all. Actually it looks as if you may be able to tweak it to over 50 incomplete connections, but 50 seems fine enough to me.

For good measure MS also decided, with sp2, to block access to raw sockets, on the grounds that 'only attack programs use them.'

BTW, if you need the speed increased after that, you'll have to look at tweaking the connection. Rummage around dslreports.

Kevin

Well done Kevin.

Everything, was pointing to SP2 was hoping someone would put 2+2 together and solve the problem given known issues.

Guess this needs to be sticky posted somewhere un-official after further confirmation by others with this issue. Kye-U what say you.
Add Thank You Quote this message in a reply
Nov. 04, 2005, 06:08 PM
Post: #64
 
laighleas Wrote:Well, with a bit of tweaking I've got RWin up to 257004 under all circumstances, whether Proxomitron is used or not.

Kevin

Hi Kevin,

Good news, if only that somebody with XP/Home/SP2 is seeing the correct number for RWIN.

But just to be clear:
Did you have the problem *before* you patched tcp.ip.sys?
RWIN is the number you set, after you patched tcp.ip.sys?
Do you have the problem now, if you use an unpatched tcp.ip.sys?

Anybody else using this tcp.ip.sys patch?
Like maybe HPGuru and Moserd?

--
JJoe
Add Thank You Quote this message in a reply
Nov. 04, 2005, 08:50 PM
Post: #65
 
Peakaboo Wrote:Guess this needs to be sticky posted somewhere un-official after further confirmation by others with this issue. Kye-U what say you.

Good idea.

I will do so after we reach a firm conclusion Smile!
Visit this user's website
Add Thank You Quote this message in a reply
Nov. 04, 2005, 09:39 PM
Post: #66
 
One conclusion that I draw is that the RWIN "thingy" is NOT reduced by Proxo, as the title of this thread alludes to...

But hey, what do I know... Big Teeth
Add Thank You Quote this message in a reply
Nov. 05, 2005, 03:33 AM (This post was last modified: Nov. 06, 2005 06:29 PM by Peakaboo.)
Post: #67
 
Peakaboo Wrote:If I had Windows XP with SP2 and was experiencing a slow down like Tony sites in his anchor post, regardless of whether my Event Viewer was saying I had a problem or not, I would do the following:

1) create a restore point
2) backup current tcpip.sys
3) run LvLLord's 4226 Fix - note this fix will tell you how many connections are currently allowed. http://www.lvllord.de/?lang=en&url=tools
4) restart my pc
5) download and run TCP Optimizer 2.0.2 http://www.speedguide.net/downloads.php
a) select preferences and set latency to 100 ms and press ok
b) under the general tab set the slider to your IP's advertised speed
c) select your network adapter in the drop down box
d) press optimal and if satisfied with the RWIN save it and restart the PC

The above steps will set your RWIN pretty close to what it should be and set the browser speed tweak (advanced tab) for you.

Prior to downloading future windows updates from this point forward, I would either back up my fixed tcpip.sys or run LvLLord's 4226 fix subsequent to the windows update.

What do you have to lose vs. what you can gain - cost benefit analysis says above is a no brainer IMO. Smile!

************************************

Additional evidence that the RWIN issue cited by Tony in his anchor post is a direct result of Windows XP SP2 and Event ID 4226.

I. Philip from speedguide & also TCP Optimizer author/developer fame wrote about this Windows XP SP2 and Event ID 4226 issue as early as 9/18/2004.

http://www.speedguide.net/read_articles.php?id=1497

Philip Wrote:Note the information below only applies to Windows XP Service Pack 2.

Remove the limit on TCP connection attempts

Windws XP SP2 introduces a few new twists to TCP/IP in order to babysit users and "reduce the threat" of worms spreading fast without control...

You only need to worry about the number of connection attempts per second if you have noticed a slowdown in network programs requiring a number of connections opened at once. You can check if you're hitting this limit from the Event Viewer, under System - look for TCP/IP Warnings saying: "TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts". Keep in mind this is a cap only on incomplete outbound connect attempts per second, not total connections. Still, running servers and P2P programs can definitely be affected by this new limitation. Use the fix as you see fit.

Philip references the Fix for the 4226 event by LvlLord http://www.lvllord.de/?lang=en&url=tools although when Philip wrote this up the Event ID 4226 Fix was @ v2.11 Wink LvlLord 4226 Fix is @ v2.23D now.

Philip back then also gave instructions on how to manually edit tcpip.sys for the more adventurous among us using a hex editor - heed the warnings.

_____________________________

Looks like those who have this issue can view the problem via the Event Viewer in Windows as Philip noted above.

II. More on this Windows XP SP2 and Event ID 4226 from Kasper's blog:

http://blog.davidkaspar.com/archives/200...d-4226.php

David Kasper Wrote:There is a way to tell whether your daily networking activities are being affected by the Windows XP SP2 patch. Each time your computer tries to establish more than 10 half-open connection, a system event will be logged in Windows. It looks something like this:

EventID 4226: TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts


Access the event viewer by Start / Control Panel / Administrative Tools / Event Viewer / System. Sort by Event and scroll down to 4226. If you only have a few occurrences, I would not worry about it but if you see many daily occurrences it's time to look into why they are appearing.

There are two scenarios:
1. You computer may be infected with a virus/worm that is trying to spread
2. You are a networking power users and your applications are being stalled by the XP SP2

_____________________

Note both authors Philip and David are pointing to the LvlLord 4226 fix and apparently LvlLord is staying ahead of MS:

Kasper Wrote:Certain Microsoft updates may replace the TCPIP.SYS with a new locked version but LVLLord has been quick on updating the patch. When you run the LvLLord Fix, it will tell you how many connections are currently allowed.
Add Thank You Quote this message in a reply
Nov. 06, 2005, 02:37 PM
Post: #68
 
I do not see "EventID 4226:" in my logs.

laighleas Wrote:Well, with a bit of tweaking I've got RWin up to 257004 under all circumstances, whether Proxomitron is used or not.

Is that the rwin reported at speedguide? Can you be a bit more specific on what you tweaked.

Mike
Add Thank You Quote this message in a reply
Nov. 09, 2005, 07:43 PM
Post: #69
 
JJoe Wrote:Good news, if only that somebody with XP/Home/SP2 is seeing the correct number for RWIN.

But just to be clear:
Did you have the problem *before* you patched tcp.ip.sys?

No. However, the patch wasn't in response to the problem - it was in anticipation of it, and almost immediately following my recent upgrade to sp2 from sp1. I was doing a clean install, and had left it a bit late so that all the various problems and hiccups were well known. :-) I was aware of the restrictions on tcpip.sys under sp2; I was also aware, from earlier experiments/observations with Proxomitron, that these new settings might well have a direct impact on Proxomitron's performance. I therefore patched it as a matter of course, almost immediately after the upgrade so that I didn't have a future problem. Of course, I can't rule out cocking a snoot at MS as a motive as well. :-) But mostly it was seeing an anticipated problem and dealing with it ahead of time. :-)

JJoe Wrote:RWIN is the number you set, after you patched tcp.ip.sys?

With the patched tcpip.sys the system, without any tweaks - other than having hardened the stack - gave me 65535, whether Proxo was used or not. This was the value set by Windows in the registry when it installed sp2. After spotting this thread I decided to do a few speed tweaks, after which I checked the RWIN again, and got a value of 257004 with or without Proxomitron, which is what the registry gives as the value.

JJoe Wrote:Do you have the problem now, if you use an unpatched tcp.ip.sys?

Haven't unpatched it since. :-) No point, except maybe for experimental purposes. But if I get some time, I may run the experiment. :-)

Kevin
Add Thank You Quote this message in a reply
Nov. 09, 2005, 07:50 PM
Post: #70
 
z12 Wrote:Is that the rwin reported at speedguide?

I used http://www.dslreports.com/tweaks

[quote=z12]Can you be a bit more specific on what you tweaked.

I'll check up the registry values asap and post them back. Possibly this weekend, when I've got a bit more time. At work at the moment, and don't want to rely on my memory. :-)

Kevin
Add Thank You Quote this message in a reply
Nov. 09, 2005, 10:28 PM
Post: #71
 
Hi Kevin,

I don't have XP, so I have people checking these things for me.
Some are novices and some are very knowledgeable.
All I can do is use what I am told. :-)

laighleas Wrote:
JJoe Wrote:RWIN is the number you set, after you patched tcp.ip.sys?
With the patched tcpip.sys the system, without any tweaks - other than having hardened the stack - gave me 65535, whether Proxo was used or not. This was the value set by Windows in the registry when it installed sp2. After spotting this thread I decided to do a few speed tweaks, after which I checked the RWIN again, and got a value of 257004 with or without Proxomitron, which is what the registry gives as the value.
What was done to harden the stack?

laighleas Wrote:
JJoe Wrote:Do you have the problem now, if you use an unpatched tcp.ip.sys?
Haven't unpatched it since. :-) No point, except maybe for experimental purposes. But if I get some time, I may run the experiment. :-)
When you get a chance... please experiment and report back.

I've had people try the tcpip.sys patch, no joy. :-(

z12 Wrote:I do not see "EventID 4226:" in my logs.

Which should indicate that he is not seeing the problem the patched tcpip.sys is suppose to fix. Yes?

See my dilemma?
Since you've never had the problem, I must assume that
something else you did solves the problem or
maybe the tcpip.sys patch has changed or
something most everybody but you does causes it.

What was done to harden the stack?

Thanks,
--
JJoe
Add Thank You Quote this message in a reply
Nov. 10, 2005, 03:03 AM
Post: #72
 
JJoe Wrote:What was done to harden the stack?

HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\Tcpip\ Parameters

SynAttackProtect = 2
TcpMaxHalfOpen = 100
TcpMaxHalfOpenRetired = 400
TcpMaxHalfOpenRetried = 80
TcpMaxPortsExhausted = 5 (possibly should have set this to 0; will look at this later)
TcpMaxConnectResponseRetransmissions = 2
TcpMaxDataRetransmissions = 3

EnablePMTUDiscovery = 1

EnablePMTUDiscovery should really be set to 0 for hardening, and was originally. However a setting of 0 forces the server to send datagrams of 576 bytes. OTOH, when set at 1, it may slow down establishing connections and the initial transfer speed, although it will result in better throughput large packets have to be fragmented somewhere along the line. Have for the moment set it on 1. I'll play with this setting a bit

KeepAliveTime = 300000
NoNameReleaseOnDemand = 1
EnableDeadGWDetect = 0
DisableIPSourceRouting = 2
PerformRouteDiscovery = 0

HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters

EnableDynamicBacklog = 10
MaximumDynamicBacklog =20
MinimumDynamicBacklog = 1
DynamicBacklogGrowthDelta = 20000

HKEY_LOCAL_MACHINE \SYSTEM\ CurrentControlSet\Services\Tcpip\ Parameters

EnableDynamicBacklog = 10
MaximumDynamicBacklog = 20
MinimumDynamicBacklog = 1
DynamicBacklogGrowthDelta = 20000

Now out of the above, only the EnablePMTUDiscovery turns up in speed tweaks, when it is set to 1.

Speed Tweaks

Still twiddling with a couple of these.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Interfaces

MTU = 1500

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

TCPWindowSize = 256960

TCPWindow should be a multiple of the Maximum Segment Size (MSS). MSS is generally MTU - 40, where MTU, or Maximum Transmission Unit, is the largest packet size that can be transmitted without fragmentation. MTU is usually 1500 or 1492 for PPPoE connections.

TCP1323Opts = 1
This enables large TCPWindow support, as per RFC 1323. If this parameter is not set to 1, the TCPWindow is limited to 64K. A setting of 1 disables timestamps, which add 12 bytes to the header each packet, thus reducing throughput.

GlobalMaxTcpWindowSize = 256960

If RWIN is chosen as lower than 65535, make it a multiple of MSS and turn scaling off (Tcp1323Opts = 0). Think however that I may need to recalculate this setting.

EnablePMTUBHDetect = 0

Setting this parameter to 1 (True) enables "black hole" routers to be detected, however it also increases the maximum number of retransmissions for a given segment. In most cases this should be kept to 0 (False).

SackOpts = 1

Enables SACK (Selective Acknowledgement) support, as specified in RFC 2018. SACK is particularly important if using large TCP Window sizes.

Still have to add some further tweaks:

DefaultTTL - recommended setting is 64
TcpMaxDupAcks ? recommended setting is 2

But those are for later.

You don't have to set this lot by hand - and in some cases you're having to create keys. Instead you could use Drtcp or TCPOptimizer to do it automatically.

Extra bits

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]

?NetFailureCacheTime?=dword:00000000
"NegativeSOACacheTime? =dword:00000000
"MaxNegativeCacheTtl"=dword:00000000

And a little registry addition I found and ran:

[HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:00000020
"MaxConnectionsPer1_0Server"=dword:00000020

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:00000020
"MaxConnectionsPer1_0Server"=dword:00000020

HTTP 1.1 specifies that a client can only open up to two simultaneous connections, e.g. one to download text, the other to download images. Anything more than that is queued. OTOH, increasing this value means that the PC can ? if the server allows it - open multiple connections and (for example) download more than one image at a time, thus loading the page faster. It?s worth trying on broadband. On the other hand some servers may enforce the spec to avoid connection hogging, though actually you only hog connections for a much shorter time, leastways on broadband. This one is a bit experimental, and I?ll probably reduce it to somewhere between decimal 4 and 10, which would be a more reasonable value than the one in this registry tweak. It is a bit excessive! :-)

Anyway, that's all the relevant fiddling so far.

JJoe Wrote:
z12 Wrote:I do not see "EventID 4226:" in my logs.

Which should indicate that he is not seeing the problem the patched tcpip.sys is suppose to fix. Yes?

It would do.

JJoe Wrote:See my dilemma?

Yup.

JJoe Wrote:Since you've never had the problem, I must assume that
something else you did solves the problem or maybe the tcpip.sys patch has changed or something most everybody but you does causes it.

Hmm! Well, I just went over to check the speedguide page, and it seems that it gives very different results from dslreports, even with Proxomitron disabled.

Anyway, with speedguide's analyzer (http://www.speedguide.net/analyzer.php) I get an RWIN of 32768 with Proxomitron, with the filters disabled. Dumping the proxy connection in IE6 tools/options gives an RWIN of 257004 (Yup, the latest bit of fiddling put it up). With Proxomitron's filters engaged, I again get a value of 32768.

OTOH, over at http://www.dslreports.com/tweaks I get 257004 with Proxomitron engaged and the filters running.

Interesting. <scratches head!> So - off to speedguide's FAQ on their analyzer:

2. How Does It Work?

The Analyzer reads the information stored in TCP/IP packet headers that are sent from your PC to our server. It does not read your Registry in any way, it simply reads packet headers containing information about your TCP/IP settings. This is the most accurate method we're aware of, since it is OS-independent, and the Analyzer sees what your end actually advertises to external servers (which, in some cases differs from the system configuration).

As the server receives a SYN packet, it extracts the TCP options from it and remembers them, along with the remote port and IP pair. It then continues listening for other packets, which usually arrive (the browser must send at least "GET /" in order to receive any data). Once the browser request is complete, the server sends the simplified web page content, complete with instructions to the Analyzer parser script.

9. I set my RWIN to N, but the Analyzer shows something slightly different. What gives?

While you can enter any RWIN value in the registry, the TCP stack will only accept some values. The value you see on the page is the best compromise between what you entered and what the stack is willing to accept. TCP headers only contain an unscaled RWIN value lower than 65536 and a scale, or rather shift factor used for larger RWINs. Valid RWIN values must be divisible by 2^shift factor. That can create slight differences however the value that the analyzer reads is what every other server on the net will get as well.

14. The Analyzer does not show my MTU value correctly ?

The Analyzer extracts values drectly from packets that your system sends to our server. In other words, the MTU shown is what gets advertised to servers on the Internet.

The most likely cause of different MTU than what you have set for your Registry (using the Optimizer or manually) is that a NAT router on the path is limiting the MTU to a lower value. If you're behind a router, update it to the latest firmware and make sure that its MTU (if user sellectable) is set to the same value. If you are behind a router with recent firmware and no options to change MTU, you can always test whether it's the culprit by removing it and connecting your system to the Internet/Analyzer directly.

Other probable causes are PPPoE software on your system that uses different MTU, or in some rare cases an ISP limiting MTU values. Last, but not least make sure the Analyzer is examining your IP address and not some transparent proxy server.

Whilst under 3 it remarks that:

Note: There are still some routers and cable/dsl modems in use that modify the maximum packet size (regardless of Registry settings). If the Analyzer reports a smaller MTU and you're behind a router, you might want to try updating its firmware, or looking through its management interface for an MTU value.

OK, what to make of this? The maximum packet size isn't being modified by a router or the dsl modem - that's demonstrated by having the higher values when Proxomitron is entirely disconnected from IE6, which is then browsing the net directly. OTOH, the dslreport tester is using an applet. I'm using Sidki's filters, and have to click on "Applet: Tweak 7" to run the test. Perhaps somebody who understands Java might like to have a look and see exactly what it's doing and how.

Upshot is that the two tests are getting the info in different ways, and producing different results. Speedguide acknowledges that downstream items such as routers, dsl modems and proxies may modify the maximum packet size. Now it may be that Proxomitron is doing that, but it only really becomes apparent when you've got a test that's extracting the data directly from the packets, rather than from whatever method dslreports is using.

So I did a bit of rummaging around - whence 32768? I recall, from the dim and distant past, that Proxomitron started off as a program running under Windows 3.1. Perhaps it was a limitation built in from the early days? Found some interesting info, which might suggest that Scott actually maximised the MTU of Proxomitron, based on the RWIN of Unix servers, so that Proxomitron was operating well above anything that contemporary machines on dialup might need. Just a guess:

"Most Unix servers are observed to have an initial RWIN of 32768, suggesting that a cable modem user should have an RWIN of at least 131072, which is actually larger than Windows 95 and Windows NT can manage.

The default RWIN for Windows 9x systems is far too small at 8192, and Win9x systems will thus always display a bad impact on download speeds from uploads. Windows ME is slightly better at 16384, but still not good enough for cable."


http://homepage.ntlworld.com/robin.d.h.w...ownup.html

If that's the case, then it would look as if changes in operating systems, and the takeup of broadband, may have caught up with the MTU set by Scott.

Best I can do - it's nearly 3 am, and I've been having a good slog at this. Brain is about to go on meltdown. :-( Anyone in a position to dissect the program and see what gives? Presumably it was analysed during the development of Proximodo?

Think the bit about tcpip.sys may also be useful - have seen Proxomitron open up a hell of a lot of connections before now. I would guess that if it tried to open up more than 10 at the same time, it would hit this problem. However, on looking at the matter more closely, it may not be the issue here.

Kevin
Add Thank You Quote this message in a reply
Nov. 10, 2005, 05:45 AM
Post: #73
 
Hi Kevin,
laighleas Wrote:Hmm! Well, I just went over to check the speedguide page, and it seems that it gives very different results from dslreports
Rrrrrrrrrrats! No unaffected XP/Home/SP2 users.
Whenever I asked anybody to double check at dslreports, the test was down.
Speedguide's number is correct, btw.

laighleas Wrote:Best I can do - it's nearly 3 am, and I've been having a good slog at this. Brain is about to go on meltdown.
And I thank you for it. :-)

Sorry about the "harden stack" question. That answer must of took some time. My hope was something in there would explain why you were unaffected.

Thanks again,
--
JJoe
Add Thank You Quote this message in a reply
Nov. 10, 2005, 10:56 AM
Post: #74
 
laighleas Wrote:What was done to harden the stack?
...
SynAttackProtect = 2
TcpMaxHalfOpen = 100
TcpMaxHalfOpenRetired = 400
...

Since your tweaking, heres a little tid bit on SynAttackProtect, check out the Note:

http://www.microsoft.com/technet/prodtec....mspx#EGAA

microsoft Wrote:SynAttackProtect

Key: Tcpip\Parameters

Value Type: REG_DWORD

Valid Range: 0, 1

0 (no SYN attack protection)
1 (reduced retransmission retries and delayed RCE [route cache entry] creation if the TcpMaxHalfOpen and TcpMaxHalfOpenRetried settings are satisfied and a delayed indication to Winsock is made.)

Note: When the system finds itself under attack the following options on any socket can no longer be enabled: scalable windows (RFC 1323) and per adapter configured TCP parameters (Initial RTT, window size). This is because when protection is functioning the route cache entry is not queried before the SYN-ACK is sent and the Winsock options are not available at this stage of the connection.

Default: 1 - enabled for Windows Server 2003 Service Pack 1, 0 -disabled for Windows Server 2003 with no service packs installed

Recommendation: 1

Description: SYN attack protection involves reducing the amount of retransmissions for the SYN-ACKS, which will reduce the time for which resources have to remain allocated. The allocation of route cache entry resources is delayed until a connection is made and the connection indication to AFD is delayed until the three-way handshake is completed. Note that the actions taken by the protection mechanism only occur if TcpMaxHalfOpen and TcpMaxHalfOpenRetried settings are exceeded.



Mike
Add Thank You Quote this message in a reply
Nov. 10, 2005, 12:18 PM
Post: #75
 
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
Add Thank You Quote this message in a reply
Post Reply 


Forum Jump: