Replies: 2 comments 4 replies
-
|
I think the library should be "lighter" in this respect, namely it's up to the user to retry but also I can see how that may not be convenient especially if they want logic similar to what's in the tool. I don't know why we'd single out connrefused for this though since it is unlikely. The other situations where the user may want to retry are more common. |
Beta Was this translation helpful? Give feedback.
-
|
Oops I may have jumped the gun on this. Are you saying that you want libcurl to continue on to connect to the other addresses (a la happy eyeballs style) if an address returns connection refused? I don't think we need an option for this -- as in it could be made the default -- and it strikes me as independent of the logic in the tool to retry a transfer that has returned connection refused. |
Beta Was this translation helpful? Give feedback.
-
|
No, the ip happy eyeballing will try other addresses when one fails for whatever reason. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, OK |
Beta Was this translation helpful? Give feedback.
-
|
On TCP connections, the ECONNREFUSED is, I think, a pretty clear indication that no one is listening. Restarting production-use servers usually install new listeners first before taking the old ones down. So, that is not a problem on TCP. On UDP, the routing of incoming packets is not really supported by the OS (unless a server installs its own eBPF based routing) and QUIC connections being refused happens during restarts. I thought it worth it retrying the connection automatically in such cases because otherwise the user experience would suffer. We can say this should all happen in the tool and not the library, but I'd expect other applications having the same need. Then this becomes a matter of balance, simplicity/usability. Adding a |
Beta Was this translation helpful? Give feedback.
-
|
The code to do this is basically already there in |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
As has been raised in #18748, there are situations where people want curl/libcurl trying to connect to a server even if it refuses attempts. Hence, I assume, the addition of
--retry-connrefusedto the command line.This command line option by itself currently has no effect. Only when adding
--retry numat least and--retry-max-time secsprobably in addition, it does something. All this is handled incurlonly.libcurlknows nothing about it.We could make
--retry-connrefusedinto aCURLOPT_RETRY_CONNREFUSEDand have the handling implemented in the ip happy-eyeballs filter. It would be limited byCURLOPT_CONNECTTIMEOUTand useCURLOPT_HAPPY_EYEBALLS_TIMEOUT_MSas the delay between attempts.It seems a better (and computationally cheaper) way to implement that option.
Beta Was this translation helpful? Give feedback.
All reactions