• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 40 subscribers
  • Views 179 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC3235SF: ERR_CONNECTION_TIMED_OUT

Marvin Gasis Arcangel
Expert 8990 points
Part Number: LAUNCHXL-CC3235SF

Hi Team,

I am posting on behalf of the customer. Kindly see the details of the issue below:

The customer is experimenting with a small webserver with 20 files, images, styles, scripts and pages.

When HTTPS is turned on, there are instances that some files are not loaded with the net::ERR_CONNECTION_TIMED_OUT error.

This error appears after 18-22 seconds of waiting after page refresh. Moreover, these are almost always the same files.
To investigate this error, the customer did the following:
1. created 2 separate projects
2. AP mode is enabled immediately after the start
3. HTTPS enabled (used dummy key and certificates).
4. Enabled capture of NWP logs.
5. Created 49 files with pictures numbered from 001 to 049 (this is one file with different names).
6. Created 2 html pages that open all pictures. On the first page files are opened in ascending order, on the second in descending order.
The error can be seen if you open Browser -> Developer Tools -> Network, refresh the page and wait for the page to fully load.
If the page loaded without error, then refresh the page again. the customer gets an error 2 times out of 3.
The file with an error on the page is always 006.png in ascending order, and on the page in descending order it is always 044.png.
On both pages it is always the 6th file in a row.
I have attached the logs provided by the customer below:
I hope you can help.
Regards,
Marvin
  • 0
    TI__Guru 61526 points

    while this is a simple test for a commercial http server, it is more complicated having the limited resources on the NWP. 

    We have only couple of sockets (3-4) allocated for the internal HTTPS and each file requires its own secure socket. Is there areal requirement to support 50 images?

    From a first look at the log i couldn't find specific evidence (i'm not sure it will be possible to get one and we will need to consult about it internally) but it seems that the NWP can get into situation where there is no socket to accept the connection and connection request may get dropped. 

    If possible please ask the customer to use less than 50 images (note that the internal order of loading images is not necessarily in the order in the page, and according the NWP log the 4th and 5th files are loaded after more than 30 other files (the request for the 6th file itself can't be seen in the log). 

  • 0 in reply to Kobi Leibovitch
    TI__Expert 8990 points

    Hi Kobi,

    Thank you for supporting us on this case. Kindly see the customer response below:

    Kobi Leibovitch said:
    Is there areal requirement to support 50 images?
    No, I don't need to upload so many images at the same time.
     
    I created this project to investigate the described error, it has nothing to do with a real project. All requests are written so that the error appears as often as possible.
     
    In my real web server, about 10 files are downloaded at the same time. But in this case, the error appears rarely, approximately 1 error per 20-30 page updates. But even in this case, some resources are loaded in 5-10 seconds. I don't think it should be like that.
    Regards,
    Marvin
  • +1 in reply to Kobi Leibovitch
    TI__Guru 61526 points

    As mentioned before the internal HTTP server is limited in resources but it works fine with most of the simple use-cases. 

    If the actual download time is too long, i would recommend trying to optimize the HTML content. We can also check logs (NWP, sniffer) and see if we can improve anything. 

    The customer always have the option to try an external HTTP server implementation (i.e. one that is implemented on the host) . The SDK has one reference (under source/ti/http/) but the customer can choose a different one and port it so it will work on top of the SimpleLink Sockets.