cc3200 strange socket accept behavior

Hello PM,

Some questions from my side to understand better:

• I see from the figure that you are downloading some components from the server into the browser like jpg/scripts/png. Are these components reside on the serial flash of the device? how do you manage it on your HTTP server? please explain the flow from browser to HTTP server.
• what HTTP port are you using? something proprietary? did you disable the internal HTTP server in the device?
• in case we need it, do you have a sniffer capture you can share?

Regards,

Shlomi

Hello Shlomi,

1. Yes, all files are stored in internal serial flash. I use SimpleLink API (sl_Read) to access these files. The flow is: Accept connection, Parse HTTP request, find file, send HTTP response headers, send FILE, close connection. I process one connection (HTTP) at a time.
2. I have disabled internal HTTP server and use port 80.
3. Can I send you Wireshark output directly to you?

Regards,
PM

yes, please use shlomii@ti.com

Hello,

Looking in the sniffer capture, I do not see the HTTP GET to bg.jpg at the order at which it appear on the screenshot.

It is only captured on sniffer towards the end.

I can also see many resources that do not appear on the screenshot, like *.map files.

Can you elaborate?

Shlomi

Hello,

I believe *.map files are filtered out by Chrome and I do not see option to turn them on. I do not also believe if the order from the screen shot is the same as in Wireshark output. Anyway, I have sent you debug log from my device.

Thanks,
PM

Additionaly, I also used CURL application for testing and saw the same problem. I requested for 10 files at the same time and I saw the same problem. 3 files were downloaded correctly, the next file were delayed for 2-3 seconds, etc. I use Chrome to see network requests and responses.

Thanks,
PM

Shlomi,

Sorry for bothering you. I have performed the same test using Firefox. Result is the same, two last files were delayed. I have sent you files.

Regards,
PM

Hello,

Another day of my investigation. What i see in Wireshark is TCP retransmission occurances durign delays between two HTTP requests. Screens below:

Regards,

PM

Hello PM,

I reviewed the sniffer logs and the latest retransmissions that you see.

SimpleLink device network stack has built in limitations since it is running on embedded system with limited resources after all.

You can have up to 7 sockets where the memory you can use for packets allocation is also bounded (you can see from the TCP window size).

Buttom line, in your case you open several connections simultaneously as can be seen on sniffer.

Each connection that is openned is followed by SYN packet sent to the SimpleLink device and the devie should respond with SYN packet back. At the end of this handshake, the host can call sl_accpet() and get a valid socket descriptor back. When the handshake is not done, you would get -11 and you should retry.

This is what happen in your case, since you are trying to open many connections at the same time, and the chrome starts counting from the 1st SYN that is sent by the browser, it happens that not always the SimpleLink can fulfill the connection and the browser needs to retry (as it does).

This is why you see the retransmission. The timeout between retransmissions is browser dependent but eventually you see that it suceeds.

I hope it adresses your questions.

Regards,

Shlomi

Hello,

Any update on the post?

Regards,
Shlomi

Hello,

I am closing the thread for now.
If issue still exist or you have further related doubts please open a new thread and add a link to this one for reference.

Regards,
Shlomi