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?"
Knowing Windows, it's probably some obscure undocumented registry key somewhere which you need to twiddle... Fun :)
You have to give the windows client time to reboot.
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.
- For the complete works of Shakespeare: cat
Is HKLM\System\CurrentControlSet\Services\Tcpip\Param eters
e sk it/en-us/default.asp?url=/windows2000/techinfo/res kit/en-us/regentry/58811.asp
REG_DWORD
30
Setting this to anything below 30 decimal will just set it to 30 anyway though.
http://www.microsoft.com/windows2000/techinfo/r
RTFQ FFS! Idiot.
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
Informative?
You idiots! He's looking for the windows alternative to that.
Morons, you and your moderator.
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?
"When I grow up, I want to be a weirdo"
Its still a stupid story.
Lets get an update on the KiSS -vs- MPlayer thing already.
Was your post funny? NOT REALLY.
Was your post helpful? NO.
Was your post interesting? NO.
Was your post original? NOT IN THE SLIGHTEST.
Obviously people like you who aren't working in high pressure tech jobs (and by extension are probably still loafing in our parents' basements) can easily install Debian. But those of us in the real world with bosses screaming at us about deadlines don't have such luxury.
Next time, don't bother posting and save us all the mental energy of not having to read your stupid crap.
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!
likewise, fucktard
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.
/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.
/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?
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
Even better, looking in
The living have better things to do than to continue hating the dead.
can change hard-coded values in Linux source code and recompile.
did you try looking in the freebsd handbook .......
bu bum tshhhh
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.
The URL you just referenced lives at nonstandard port 81: Does the Google spider look for nonstandard ports?
do i maybe feel a *little* bit of frustration out of your post? if you call working 12hrs a day to meet insanse sw release dates a high pressure tech job or not is left as an exercise to you.
so you'd rather not install debian because of deadline issues? kind of shows the level of technical experties you have...
the rest of your post is just so ridiculous there's really no need to reply to it. did you even notice your own post applies to your very post more than it does to my post?
p.s.: for someone not even having the guts posting with his username on a website you open your mouth maybe a little bit too wide...
Browse Slashdot at Funny+5, everything else -5. The only way to sustain it.
As far as I know every platform that Windows runs on can also run Linux. Shouldn't it be easy to just reformat your Windows servers to install the necessary software to do what you need (Linux)? Is there something I'm not getting here, or were you perhaps unaware of this possibility? If the later is the case, I hope this post will be helpful to you.
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.
n/t
is always a viable option! So are: A) insert *distro of choice* install media B) change server side params C) live with it?
I've found that disabling the delayed ACK on Windows servers generally fixes all problems I've had with Windows->unix communication.
MS even has a technet article on it, actually a few.
Need Free Juniper/NetScreen Support? JuniperForum
Hahaha, dork. Just admit you didn't read the question. It's ok you know, this is only slashdot.
You are free to do as we tell you.
We want your soul.
www.wewantyoursoul.com
Dude, switch to decaf and quit being a sarcastic asshole.
Ummm... I think my parents should be calling the cops if any of you are loafing around in their basement.
Un-news
I already did. Dork.
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
Stop calling names, you fucking idiot.