Unix TCP Equivalent Settings in Windows 2000?

sameerdesai asks: "While working on a project that required client-server functionality I was running into processes that wouldn't finish and eventually hang. While running packet tracing, I found out the tcp_fin_wait_2_timeout setting on the server side (UNIX) was too low for the Windows client, and after increasing that value it worked great. I am trying to apply a similar technique for a Windows server and was wondering what the equivalent registry key is for UNIX's tcp_fin_wait_2_timeout setting? Also, is there a guide out there that compares TCP setting in UNIX with Windows?"

Comments

Reboot

[tgeerts]

You have to give the windows client time to reboot.

Danger Wil Robinson...

[hoggoth]

I will not deploy any software that requires me to start tweaking obscure registry values that change my server's basic TCP behavior. I'm sure I'm not alone in this.

I don't know what you are planning to do with this project, ie: sell it to the masses, make it open source, use it in house. Just keep this in mind.

Re:Danger Wil Robinson...

[Curtman]

Thats a very unrealistic thing to say. There is no magical configuration that will be optimal in all circumstances. Tweaking your registry to try and get a few extra FPS out of Doom3 is one thing, but administering a large database with many users is something completely different.

Re:Danger Wil Robinson...

[Bravo_Two_Zero]

Whoa... that may be a little harsh. How is this different from sysctl settings in the BSDs? Granted, the registry is a bit more nebulous, since you can't see/set values with a simple `sysctl -whatever`. But most reg settings are binary on/off settings. And their changing can be batched for easy reproduction. It's unfair to deride a solution merely because it's not "your" kind of obscurity.

Is it ideal? Certainly not. I'd never advocate changing window size on a whim (or even as a means of hiding system type, as some security gurus suggest). But it certainly isn't unreasonable.

The registry key for windows

[esac17]

Is HKLM\System\CurrentControlSet\Services\Tcpip\Param eters
REG_DWORD
30

Setting this to anything below 30 decimal will just set it to 30 anyway though.

http://www.microsoft.com/windows2000/techinfo/re sk it/en-us/default.asp?url=/windows2000/techinfo/res kit/en-us/regentry/58811.asp

Re:The registry key for windows

[sporktoast]

Looks like you forgot to mention one thing, and the slashed up URL made it slightly more difficult to discover.

There are about a hundred different entries contained in HKLM\System\CurrentControlSet\Services\Tcpip\Param eters. The REG_DWORD in question is the one labeled "TcpTimedWaitDelay". Accepted values are between 30 and 300 (seconds).

Did you look here?

[cnvogel]

Maybe this document is enlightening? http://www.microsoft.com/windows2000/techinfo/resk it/en-us/default.asp?url=/windows2000/techinfo/res kit/en-us/regentry/33563.asp

Re:Today on Ask Google

[DjReagan]

Now why didn't I think of looking in /proc on my Windows machine? Oh yeah.. that's right.. its because IT DOESN'T EXIST.

Now, if I was doing on my Linux machine, that would work fine. But that wasn't what the guy's question was now, was it?

Fishy

[ezzzD55J]

This state is the amount of time a TCP implementation will keep a TCP connection open that it has closed itself, i.e., sent a FIN for (it has no more data to send). However, the other TCP is still allowed to send as much data as it likes, until it sends a FIN (once that FIN is ACKked by this side, _then_ the connection is really released - all that remains is the blue/red army problem which isn't the topic now).

So, what is this application doing relying on a timeout value in this phase? It would be terrible to be dependent on a TCP implementation in an application!

User Friendly

[dpilot]

Because of course using regedit to tweak the value of HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Param eters is MUCH more intuitive and user friendly than doing something in /proc/sys/net/ipv4. Actually, I don't see any sort of tcp_fin_wait_2_timeout in there, nor do I see anything that looks like an equivalent parameter in the Windows help page. At least I see tcp_fin_timout in /proc, but don't see anything like it in the registry documentation page.

On a slightly more usable scale, if I'm going to use an obscure interface, at LEAST I'd prefer it be in cleartext than some odd binary thingy that can only be edited with a special tool. OK, perhaps /proc and the Registry are equally binary, since the tools let you plug in equivalent numbers. But it remains that I can do directory navigation on /proc, and must use a special tool for the Registry.

Even better, looking in /usr/src/linux/Documentation/networking/ip-sysctl. txt I find that tcp_fin_timeout is indeed used to control the time to hold the socket in FIN-WAIT-2, so it turns out that it is indeed the correct parameter. That still doesn't help me find the same parameter in the Microsoft documentation, which is on the web, not on the system, and if I can't get the networking running, how do I search?

Re:User Friendly

[shufler]

Ubscure interface?

REGEDIT [/v|-v] [/s|-s] <FILENAME>

[/s|-s]
When a filename is specified on the command line, this switch is used to suppress any informational dialog boxes that would normally be displayed. This is useful when the Setup program for an application wants to execute REGEDIT.EXE with a .REG file, but does not want the user to be confused by any dialog boxes that are displayed.

Put what you need in the file you wish to import.

http://support.microsoft.com/default.aspx?scid=htt p://support.microsoft.com:80/support/kb/articles/Q 82/8/21.ASP&NoWebContent=1

Re:User Friendly

[dpilot]

"REGEDIT " isn't the obscure part. Just IMHO everything about the bits and handles after that is about equally obscure between regedit and /proc. Both are equally unfriendly. But you can do /proc without a special GUID program, so also IMHO it wins the toss.

Re:User Friendly

[shufler]

I never said Regedit was better! However, as mentioned many times above, /proc is most definately not available in Windows. The question was to find a solution for Windows. I was merely showing you could handle the registry using a command line utility (which is technically the very same program used to edit in the Windows GUI). It uses text files and simple CLI commands, which can be implemented from a batch or install process.

For example, if the final solution for the original question requires a reg hack on every client it is installed on, this would be the easiest way to implement the change, short of using Registry objects (or their equivalent) in whatever programming language you're using.

You can also view the registry without a GUI: there is an export switch (/E outfile.reg), which I beleive outputs the registry to a text .reg file.

All these switches should work in every version of Windows that uses the registry -- that includes Windows 3.x.

Why bother tweaking registry values when you

[Anonymous Coward]

can change hard-coded values in Linux source code and recompile.

unix to windows rosetta stone

[lylonius]

rosetta stone: performance tuning

this is conceptually similar to http://bhami.com/rosetta.html, but my table focuses on design choices, specifically performance and security tuning, not daily operations.

note: i couldn't find a value for windows TCP FIN timeout (fin-wait-[12]). The TcpTimedWaitDelay that somebody else suggested is for the TCP TIME_WAIT.

URL lives at nonstandard port 81

[mosel-saar-ruwer]

The URL you just referenced lives at nonstandard port 81:

http://foureleven.org:81/rosetta-stone-performance -tuning.html

Does the Google spider look for nonstandard ports?

Re:I don't get it

[Anonymous Coward]

Shouldn't it be easy to just reformat your Windows servers to install the necessary software to do what you need (Linux)?

Either you are a teenager who has never had a real IT job or you are an adult working in a field that has no relation to IT. I mean there is simply no way that someone who actually works in the real world on actual production servers would say something as stupid as "reformat and install linux."

Re:I don't get it

[the last username]

Sure. All you have to do is...

Convince IT management it's a good idea

Reduce Windows IT support headcount (make people redundant)

Hire Linux IT support/developers

Obtain budget for new hardware (I assume you didn't really mean that all the other apps on that server have to be ported from Visual Basic, so we're actually talking about a new server here)

Explain increased staff costs and new hardware to senior management

Explain free, "unsupported" software to senior management (or did you want funding for a Redhat support contract too?)

Convince senior management it's a good idea

Then either...

Install Linux

Port app to Linux

Test

or...

Update CV (called a resume in French)

Hit the job websites

Phew! Well, at least you didn't have to...

Change a single registry setting on an otherwise working system

I'm happy running Linux at home (actually I run BSD, but that's besides the point), but I'd need a damn good reason before I'd suggest "just installing Linux" in a Windows-only shop.

Re:I don't get it

[the last username]

They don't have a Windows-only shop. They already have a good operating system on some of their servers (as mentioned in the post).

Fair point. Although it isn't absolutely clear - the questioner had previously worked on a project with a Unix server component. They didn't say whether it was at the same company, or whether that company might have been working for two different clients.

My point was that there are many factors you need to take into account before deciding to switch platform, technical and otherwise. The great-grandparent asked what the problem was; I was saying that the capability of the hardware to run Linux and the simplicity of the Linux install process (both identified as pertinent by the great-grandparent) are possibly the two most trivial factors.

The questioner may now be working or consulting for a Windows-only shop, in which case hiring someone to support a non-standard (for that environment) system after the questioner is gone would be a significant cost. The server component for this project may require significant development to port to Linux - or may be closed-source and third-party. Maybe the project is to develop a server component that can be sold to Windows-only clients as well as to Linux-friendly clients. Or maybe it's a true heterogenous environment, and the decision to implement this particular project on Windows was made for sound technical reasons.

As for the rest of your post, I'm a little confused. You claim to buy in to the B.S. about Windows being so trivial it doesn't even require support staff (MS don't claim that - they offer certification for support staff!), but then you claim that Windows can't compete in any category with Linux.

That's an incredibly strong claim. Not just inferior to Linux in many categories or even inferior to Linux in every category. Can't even compete, in any category? I guess that explains why Windows has such a minuscule share of the market.

Here's how to do it

[swissmonkey]

1) Go get the relevant hotfix for it (kb813056) from MS support : http://support.microsoft.com/default.aspx?scid=kb; en-us;813056

2) Go to HKLM\SYSTEM\CurrentControlSet\ Services\TcpIp\Parameters and add the reg key TCPFinWait2Delay

3) Set the reg key value to the appropriate delay you want