Closed STRATZ-Ken closed 4 months ago
I suspect this is by design: the connection is kept open to save time and resources in case the program wants to do further HTTP requests to the same host. You should be able to use CURLOPT_FORBID_REUSE to stop this from happening.
Hello Dan,
Thanks for such a quick reply.
Yes, I have tried that. It still opens sockets.
I don't know what that second image is showing. Of course it is still going to open a socket—it needs to talk to the server. The question is, does it close the socket afterward? Actually, in looking at the first log you shows, it even says "* Closing connection". How are you determining that the socket is actually kept open?
Hello Dan,
This is the windows resource monitor. It shows all open sockets for a specific application. When the socket closes, it will gray out. As you can see this is just looping and keeps creating more sockets forever. When I try to connect to wss://welcome.hello for example, it attempts to connect but instantly fails and the socket is immediately closed. (Hostname failure instead of http status code 200)
Sent from my iPhone
On May 29, 2024, at 7:27 PM, Dan Fandrich @.***> wrote:
I don't know what that second image is showing. Of course it is still going to open a socket—it needs to talk to the server. The question is, does it close the socket afterward? Actually, in looking at the first log you shows, it even says "* Closing connection". How are you determining that the socket is actually kept open?
— Reply to this email directly, view it on GitHubhttps://github.com/curl/curl/issues/13829#issuecomment-2138411834, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AF6S7HMJP6F4THWYM6QYNQTZEZP4ZAVCNFSM6AAAAABIP2F2QCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZYGQYTCOBTGQ. You are receiving this because you authored the thread.Message ID: @.***>
Are you sure the socket isn't actually in FIN_WAIT1 or TIME-WAIT or some other closing-but-not-quite-closed-yet state?
As @dfandrich, I suspect this is the #13153 issue: the connections are not left alive, they are in some wait states.
Sorry, I am still debugging to hopefully collect more information.
So to the best of my knowledge, it is in-fact closing correctly. However the UI on Windows Resource Monitor is not function to the correct closing. It works fine with LibCurl POST/GET, but on Websockets it doesn't show it closing, however netstat -an
does show it in TIME_WAIT status (Closed). I would consider this technically closed, though there is a very small bug I am not sure it warrants further investigation.
I did this
I expected the following
During the above code test, I noticed that my application was crashing after just a short period.
When I attempt to go an unknown host such as wss://121231231312313.com the application will work as expected. The socket will close upon it failing to connect. However, when going to a domain where the connect could be alive but gets a 403 or 200 (but fails to connect, such as wss://123.com) the output will say failure but the socket will remain open on the host. After a while I get socket exhaustion.
Sorry, the code is in C#. If we wait about 180 seconds, they will eventually timeout but this is already too late when using a lot of calls.
curl/libcurl version
Curl 8.5.0
operating system
Windows 11 OS.