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://

9 months ago • •

daniel:// stenberg://

9 months 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:// • 9 months 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:// • 9 months 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:// • 9 months 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:// • 9 months 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:// • 9 months 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:// • 9 months 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 • 9 months 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 • 9 months 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 • 9 months 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 🌸
mastodon - Link to source

Alba 🌸

Unknown parent • 9 months 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:// • 9 months 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 • 9 months ago • •
@mildsunrise @shaknais after a RST because nothing is listening?
@James 🌈💜 @Alba 🌸
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

Alba 🌸
mastodon - Link to source

Alba 🌸

in reply to daniel:// stenberg:// • 9 months 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 • 9 months 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 🌸
mastodon - Link to source

Alba 🌸

in reply to Alba 🌸 • 9 months 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:// • 9 months 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 (yeah fosdem)
akkoma - Link to source

mi (yeah fosdem)

in reply to 🇨🇦 Dianne S • 9 months 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 (yeah fosdem)

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

daniel:// stenberg://

in reply to mi (yeah fosdem) • 9 months ago • •
@mi @dfs_comedy try "curl localhost:6789" and then we think about retried SYNs 😁
@mi (yeah fosdem) @🇨🇦 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:// • 9 months 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 (9 months ago)
  •  Languages
  •  Search Text
  •  Share via ...
in reply to daniel:// stenberg://

Eugen Neuber
mastodon - Link to source

Eugen Neuber

in reply to daniel:// stenberg:// • 9 months 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 • 9 months 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 ...
⇧