Friendica
daniel:// stenberg://

daniel:// stenberg://

bagder@mastodon.social
daniel:// stenberg://

daniel:// stenberg://

bagder@mastodon.social
I write curl. I don't know anything.
ActivityPub
2024-08-11 09:09:22 2024-08-07 09:23:36 2024-08-07 09:23:34 5290213

daniel:// stenberg://
daniel:// stenberg://
mastodon - Link to source

daniel:// stenberg://

1 year ago • •

daniel:// stenberg://

1 year ago • •


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
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

daniel:// stenberg://
mastodon - Link to source

daniel:// stenberg://

in reply to daniel:// stenberg:// • 1 year ago • •

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
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

Derick Rethans
mastodon - Link to source

Derick Rethans

in reply to daniel:// stenberg:// • 1 year ago • •
This explains a lot for several of my bug reports too...
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

Derick Rethans
mastodon - Link to source

Derick Rethans

in reply to daniel:// stenberg:// • 1 year ago • •
Please post here if you've come up with something cool (so that I can "steal" it ;-) ).
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

Christian
mastodon - Link to source

Christian

in reply to daniel:// stenberg:// • 1 year ago • •
this is so annoying when doing a typo while using ssh client in powershell.
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

simendsjo
mastodon - Link to source

simendsjo

in reply to daniel:// stenberg:// • 1 year ago • •
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
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

LisPi
pleroma - Link to source

LisPi

in reply to daniel:// stenberg:// • 1 year ago • •

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

That's kind of gross and annoying.

  •  Languages
  •  Search Text
  •  Share via ...
in reply to LisPi

daniel:// stenberg://
mastodon - Link to source

daniel:// stenberg://

in reply to LisPi • 1 year ago • •
@lispi314 not to my knowledge , no. Only a registry key that then of course changes every application in the system.
@LisPi
  •  Languages
  •  Search Text
  •  Share via ...
Unknown parent

daniel:// stenberg://
mastodon - Link to source

daniel:// stenberg://

Unknown parent • 1 year ago • •
@shaknais yikes, yeah that is totally out of the question...
@James 🌈💜
  •  Languages
  •  Search Text
  •  Share via ...
Unknown parent

daniel:// stenberg://
mastodon - Link to source

daniel:// stenberg://

Unknown parent • 1 year ago • •
@mildsunrise @shaknais Ideally I would avoid the retry of the SYN, like the rest of the world does
@James 🌈💜 @Alba 🌸
  •  Languages
  •  Search Text
  •  Share via ...
Unknown parent

Alba 🌸
glitchsoc - Link to source

Alba 🌸

Unknown parent • 1 year ago • •
@shaknais you do want the SYN to be retried, just not when you've received an RST indicating the port is closed
@James 🌈💜
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

Pedro Pérez
mastodon - Link to source

Pedro Pérez

in reply to daniel:// stenberg:// • 1 year ago • •

@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 🌸
  •  Languages
  •  Search Text
  •  Share via ...
Unknown parent

daniel:// stenberg://
mastodon - Link to source

daniel:// stenberg://

Unknown parent • 1 year ago • •
@mildsunrise @shaknais after a RST because nothing is listening?
@James 🌈💜 @Alba 🌸
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

Alba 🌸
glitchsoc - Link to source

Alba 🌸

in reply to daniel:// stenberg:// • 1 year ago • •
@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 🌈💜
  •  Languages
  •  Search Text
  •  Share via ...
Unknown parent

daniel:// stenberg://
mastodon - Link to source

daniel:// stenberg://

Unknown parent • 1 year ago • •
@mildsunrise @shaknais let me phrase it like this then: I want the Linux behavior on Windows too
@James 🌈💜 @Alba 🌸
  •  Languages
  •  Search Text
  •  Share via ...
in reply to Alba 🌸

Alba 🌸
glitchsoc - Link to source

Alba 🌸

in reply to Alba 🌸 • 1 year ago • •
@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 🌈💜
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

🇨🇦 Dianne S
mastodon - Link to source

🇨🇦 Dianne S

in reply to daniel:// stenberg:// • 1 year ago • •

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.

  •  Languages
  •  Search Text
  •  Share via ...
in reply to 🇨🇦 Dianne S

mi -> WHY2025
akkoma - Link to source

mi -> WHY2025

in reply to 🇨🇦 Dianne S • 1 year ago • •
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?
  •  Languages
  •  Search Text
  •  Share via ...
in reply to mi -> WHY2025

daniel:// stenberg://
mastodon - Link to source

daniel:// stenberg://

in reply to mi -> WHY2025 • 1 year ago • •
@mi @dfs_comedy try "curl localhost:6789" and then we think about retried SYNs 😁
@mi -> WHY2025 @🇨🇦 Dianne S
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

🇨🇦 Dianne S
mastodon - Link to source

🇨🇦 Dianne S

in reply to daniel:// stenberg:// • 1 year ago • •

$ 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 year ago)
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

Eugen Neuber
mastodon - Link to source

Eugen Neuber

in reply to daniel:// stenberg:// • 1 year ago • •
maybe they expect this behavior from other Windows computers/servers? (missing the SYN)
  •  Languages
  •  Search Text
  •  Share via ...
Unknown parent

daniel:// stenberg://
mastodon - Link to source

daniel:// stenberg://

Unknown parent • 1 year ago • •
@kurtseifried I don't know, I have not tested myself. I presume it is much quicker than Windows native.
@kurtseifried
  •  Languages
  •  Search Text
  •  Share via ...
⇧