Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Windows Operating Systems Software The Internet Unix

Unix TCP Equivalent Settings in Windows 2000? 65

Posted by Cliff from the RWIN-SWIN-and-MTU dept.
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?"
This discussion has been archived. No new comments can be posted.

Unix TCP Equivalent Settings in Windows 2000? More

Unix TCP Equivalent Settings in Windows 2000?

Comments Filter:
  • Knowing Windows, it's probably some obscure undocumented registry key somewhere which you need to twiddle... Fun :)
    • Knowing Windows, it's probably some obscure undocumented registry key
      But windows is so easy to configure - everyone tells me that - you never need to edit plain text file in a directory called etc - unless you want to change the hosts file that is.

      They had TCP/IP handed to them on a plate by Berkeley, but still couldn't even get ping right.

      Let's face it - windows is a mongrel of many parts, it just has a pretty face to show the world.

    • Are you being ironic? Unix forces you to edit crappily-documented text files scattered across the filesystem.

  • Reboot (Score:2, Funny)

    by tgeerts ( 556153 )
    You have to give the windows client time to reboot.

  • Danger Wil Robinson... (Score:5, Insightful)

    by hoggoth ( 414195 ) on Monday August 23, 2004 @10:49AM (#10045543) Journal
    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... (Score:5, Insightful)

      by Curtman ( 556920 ) on Monday August 23, 2004 @10:55AM (#10045639)
      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.

    • Why bother tweaking registry values when you (Score:3, Funny)

      by Anonymous Coward
      can change hard-coded values in Linux source code and recompile.
    • 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
      • I would completely agree. These settings are optimized for a 'best fit' situation. Solaris for example is tuned mostly for a pure lan environment. We have an application that is distributed to various wan sites. I don't recall which setting we had to twiddle, but increasing a timeout saved a LOT of user headaches.

        These things are adjustable for a reason. Now they are not made easy to adjust (have to have some relativly arcane knowleduge to do so), but that's what a good sysadmin is for.
      • Whoa... that may be a little harsh. How is this different from sysctl settings in the BSDs?

        It's not - and the principle is the same. Changing default settings is a PITA and any software requiring it "just because" had better have a _very_ compelling reason for doing so.

      • Granted, the registry is a bit more nebulous, since you can't see/set values with a simple `sysctl -whatever`.

        I'm not familiar with sysctl. Can you explain why `sysctl -whatever` is "simple" and `reg query`, `reg add`, etc., in windows aren't? It seems like it would be equivalent.
    • I will not deploy any software that requires me to start tweaking obscure registry values that change my server's basic TCP behavior.


      Big freaking deal. I'll just make the change without warning you in the setup program.

      HAND.
    • Perhaps you won't knowingly. I'm no expert on just about anything but I'm sure there's been more than one software installer on Windows that modifies existing registry keys in order to make the installed software work. Odds are good you wouldn't know unless you were closely looking at what the install was doing. Odds are you wouldn't be doing that either. Which is not to say that it's either a good or bad idea to do, it's just hard because there really is no uniformity.

  • The registry key for windows (Score:5, Informative)

    by esac17 ( 201752 ) on Monday August 23, 2004 @10:56AM (#10045647)
    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 (Score:5, Informative)

      by sporktoast ( 246027 ) on Monday August 23, 2004 @12:29PM (#10046815) Homepage

      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).

    • User Friendly (Score:3, Informative)

      by dpilot ( 134227 )
      Because of course using regedit to tweak the value of HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Para m 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

      • Re:User Friendly (Score:3, Informative)

        by shufler ( 262955 )
        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://suppo [microsoft.com]

        • Re:User Friendly (Score:3, Informative)

          by dpilot ( 134227 )
          "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 (Score:2, Informative)

            by shufler ( 262955 )
            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 hac
            • I understand your position. You gotta do what you gotta do, and you were trying to achieve the same results in Windows that you had in Linux.

              It's just that most times apples-to-apples comparisons come up, it's in the desktop arena and we get the cry, "Gimp ain't no Photoshop!" or "It's not Word!" So here's an apples-to-apples comparison, and granted it's not really desktop, but it IS a user interface issue.
          • But you can do /proc without a special GUID program, so also IMHO it wins the toss.

            Why is this "Informative"? This just isn't true. First, a GUID is a unique ID and has nothing to do with what's being discussed. Assuming parent meant GUI, it's still not true, as the standard windows commandline tools for manipulating the registry are quite decent.
            • Even if there are command line tools for manipulating the registry, it's still a specialized tool. You don't even need a text editor for /proc, just shell built-ins. This becomes more significant on a rescue diskette, though I guess we're getting to the era of rescue CDs, where space is much less a problem.

              Oh, the GUID was a typo.

  • Fishy (Score:5, Insightful)

    by ezzzD55J ( 697465 ) <slashdot5@scum.org> on Monday August 23, 2004 @11:25AM (#10046035) Homepage
    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 [panam.edu] 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!

  • unix to windows rosetta stone (Score:3, Informative)

    by lylonius ( 20917 ) on Monday August 23, 2004 @01:02PM (#10047253)
    rosetta stone: performance tuning [foureleven.org]

    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.
  • Windows has networking that was taken straight from Berkely. i.e. \etc\drivers\hosts being similar to /etc/hosts and Windows using Berkeley socket APIs.
  • is always a viable option! So are: A) insert *distro of choice* install media B) change server side params C) live with it?
  • Comment removed based on user account deletion

  • Here's how to do it (Score:3, Informative)

    by swissmonkey ( 535779 ) on Wednesday August 25, 2004 @06:15PM (#10073505) Homepage
    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

Slashdot Top Deals

Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman

Close