openframeworks / openframeworks/openFrameworks
ofLoadURL() function does not close the created socket
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 10.4k
- Forks
- 2.6k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 9
Description
So this problem can be spoted if you use the ofLoadURL() function on the update(). After a while you will have a bunch of sockets with the WAIT_CLOSE status and the application will fail. On win10 if you run netstat -an on the command line you will see a bunch of sockets being used there.
After some research I found out the problem may be on this function: ofHttpResponse ofURLFileLoaderImpl::handleRequest(ofHttpRequest request).
This function creates a new instance of HTTPClientSession every time it runs, HTTPClientSession * httpSession = new HTTPClientSession(uri.getHost(), uri.getPort());. And after receiving the info from the link you provided it does not destroy this instance leaving the socket open.
As I reported on the forum, https://forum.openframeworks.cc/t/repeat-usage-of-ofloadurl-causes-i-o-error-no-buffer-space-available/23747/1 I found out a quick fix (explained there). However, I think it should be better to just use the deconstructor after getting the information from the web link.
I hope this information is enough for you guys to understand the issue 💃
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in the implementation of ofURLFileLoaderImpl::handleRequest(ofHttpRequest request), referenced in the issue, and reproduce repeated ofLoadURL() calls from update(). Confirm that the created HTTPClientSession does not leave sockets in WAIT_CLOSE; done means repeated requests no longer accumulate sockets or eventually fail with the reported I/O error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100