openframeworks / openframeworks/openFrameworks

ofLoadURL() function does not close the created socket

Open
#5,149 0 comments 0 reactions 0 assignees View on GitHub

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.