Comment by ChrisMarshallNY
Comment by ChrisMarshallNY 2 days ago
The problem with doing that, is that the standard TCP timeout is 60 seconds.
All of a sudden, you are beset with 60-second hangs.
Comment by ChrisMarshallNY 2 days ago
The problem with doing that, is that the standard TCP timeout is 60 seconds.
All of a sudden, you are beset with 60-second hangs.
It wouldn't be able to open a TCP connection without knowing what IP address / interface to use.
You're right--it should outright error. You should only see timeouts like that if you were dropping the packets from some middleware or middlebox, but your client still had a valid IP address.
> All of a sudden, you are beset with 60-second hangs.
No, that's not how it works. Frankly, I'm astonished to see this claim here.
Depends.
I have a couple of apps on my computer that do exactly that.
I am looking forward to learning how it does work...
You're not thinking like a systemd developer. The right thing to do is to ignore all anecdotes and direct evidence that a problem exists. I am talking about systemd renaming your network interfaces because you added or removed hardware.
systemd should add and remove interfaces connected in the exact same hardware path with the same name they had before.
Default literally insane legacy behaviour is just vomiting eth${RAND} where RAND depends on racing conditions.
My educated guess is that people that insist on using the legacy eth${RAND} never had a surprise random firewall and routing rules suddenly apply to different interfaces at a inconvenient time, making production halt and catch on fire, yet.
> It's basic sockets.
Yup. I've done a bit of that stuff, in my time.
> If any apps are misbehaving, they're simply badly coded.
Plenty of that stuff, going around.
Might want to ease back on the "instant insult" thing. Not a good look.
I don't think you can get ENETUNREACH from recv though. If the request was sent, it'll time out.
It can cause problems to flip off the internet when you already have open connections, though there are also API to detect changes in network availability. But I don't see that as a significant problem for "I turn off my WiFi now to do performance-sensitive work". First turn off WiFi, then launch the app you need, in that order. Problem solved.
If the computer doesn't have any online network connection, shouldn't it outright error? I understand that the timeout sucks when your network is not connected to the internet but still alive, then that's an issue, but if there is no connection at all, why would the timeouts matter?