Skip to main content

turns out #Windows is slow to fail connect attempts to non-listening ports entirely on purpose because it waits and resends the SYN several times, contrary to how other TCP stacks behave.

mskb.pkisolutions.com/kb/17552…

#Windows
in reply to daniel:// stenberg://

daniel:// stenberg://
daniel:// stenberg://
• •

with this knowledge we are pondering what we can to do make things less annoying for #curl on Windows.

What now takes a few milliseconds on my Linux machine, takes several seconds on Windows. Not ideal.

#curl
in reply to daniel:// stenberg://

Derick Rethans
Derick Rethans
• •
Please post here if you've come up with something cool (so that I can "steal" it ;-) ).
in reply to daniel:// stenberg://

simendsjo
simendsjo
• •
relax, #windows users are used to it. I use #emacs with the #magit #git porcelain all day, and each operation is like that: unnoticeable delay on #linux, several seconds on Windows.
#linux #emacs #Windows #git #magit
in reply to daniel:// stenberg://

kurtseifried (he/him)
kurtseifried (he/him)
• •
how long does it take in a Linux container in WSL2 on windows? I know I have a few Linux things that take much longer in WSL2 because of filesystem shenanigans and so on.
in reply to daniel:// stenberg://

LisPi
LisPi
• •

They provide no user-level or application-level override options?

That's kind of gross and annoying.

in reply to LisPi

daniel:// stenberg://
daniel:// stenberg://
• •
@lispi314 not to my knowledge , no. Only a registry key that then of course changes every application in the system.
@LisPi
Unknown parent

daniel:// stenberg://
daniel:// stenberg://
• •
@shaknais yikes, yeah that is totally out of the question...
@James 🌈💜
Unknown parent

daniel:// stenberg://
daniel:// stenberg://
• •
@mildsunrise @shaknais Ideally I would avoid the retry of the SYN, like the rest of the world does
@James 🌈💜 @Alba 🌸 :v_pat:
Unknown parent

Alba 🌸 :v_pat:
Alba 🌸 :v_pat:
• •
@shaknais you do want the SYN to be retried, just not when you've received an RST indicating the port is closed
@James 🌈💜
in reply to daniel:// stenberg://

Pedro Pérez
Pedro Pérez
• •

@shaknais

I think @mildsunrise means you want the SYN to be retried if you just reached timeout without response (as both Linux and Windows do), but in this case the problem is Windows retries even when getting a RST, which is indeed a bit... unexpected.

@James 🌈💜 @Alba 🌸 :v_pat:
Unknown parent

daniel:// stenberg://
daniel:// stenberg://
• •
@mildsunrise @shaknais after a RST because nothing is listening?
@James 🌈💜 @Alba 🌸 :v_pat:
in reply to daniel:// stenberg://

Alba 🌸 :v_pat:
Alba 🌸 :v_pat:
• •
@shaknais I'm not sure I follow... all TCP stacks retry the SYN a few times before timing out, since either the SYN or the SYN/ACK could get lost. in Linux this is controlled by the net.ipv4.tcp_syn_retries sysctl, which defaults to 6
@James 🌈💜
Unknown parent

daniel:// stenberg://
daniel:// stenberg://
• •
@mildsunrise @shaknais let me phrase it like this then: I want the Linux behavior on Windows too
@James 🌈💜 @Alba 🌸 :v_pat:
in reply to Alba 🌸 :v_pat:

Alba 🌸 :v_pat:
Alba 🌸 :v_pat:
• •
@shaknais the thing is that Windows does not abort the process upon receiving an RST. but you do need the retry behavior, otherwise you'd be vulnerable to loss
@James 🌈💜
in reply to daniel:// stenberg://

Dianne S
Dianne S
• •

I want to be inside the head of whoever decided a SYN should be retried even after a RST is received.

"Oh well... maybe something *will* start listening on that port in the near future, so let's retry..."

SMH.

in reply to Dianne S

mi
mi
• •
maybe we don't trust the network? maybe we hope that the next SYN doesn't get intercepted? or even not simply intercepted and unreceived, but that RST are sent back to us by a malicious carrier and we still want to attempt SYN further in case of loss? or even not a carrier but just a malicious device in the coax hub?
in reply to mi

daniel:// stenberg://
daniel:// stenberg://
• •
@mi @dfs_comedy try "curl localhost:6789" and then we think about retried SYNs 😁
@mi @Dianne S
in reply to daniel:// stenberg://

Dianne S
Dianne S
• •

$ curl localhost:6789
curl: (7) Failed to connect to localhost port 6789 after 0 ms: Couldn't connect to server

(Linux, though.)

This entry was edited (1 month ago)
in reply to daniel:// stenberg://

Eugen Neuber
Eugen Neuber
• •
maybe they expect this behavior from other Windows computers/servers? (missing the SYN)
in reply to daniel:// stenberg://

Brett Edmond Carlock
Brett Edmond Carlock
• •

@dalias
What would a justification for this behavior be? I'm going to assume someone had a good reason to change from convention...

#Windows

#Windows @Rich Felker
⇧