Ethernet_STM + W5500: maximum parallel connections from same client

Working libraries, libraries being ported and related hardware
stevestrong
Posts: 1435
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Ethernet_STM + W5500: maximum parallel connections from same client

Post by stevestrong » Thu Jan 05, 2017 7:54 pm

I have a Web server application running on the BP, attached a W5500 board and an SD card, SdFat beta taking care of.
The HTML page requested by the client has 4 embedded pictures, the HTML site is loaded from the SD card and sent to the client.
As the page is loaded (almost) completely, the asserted pictures are being requested.
The problem: one of the pictures (randomly) is not loaded, the network analyzer of Google Chrome shows me the status: failed, ERR_CONNECTION_REFUSED.
W5500_network.jpg
W5500_network.jpg (80.37 KiB) Viewed 702 times
I am monitoring the activity over USB serial and I can see, the missing image request is not received by Ethernet_STM.

I thought the W5500 should allow me up to MAX_SOCK_NUM connections, which is defined to be 8.

What am I missing?

User avatar
Squonk42
Posts: 63
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France

Re: Ethernet_STM + W5500: maximum parallel connections from same client

Post by Squonk42 » Thu Jan 05, 2017 9:00 pm

Hi Steve,

Just a guess: can you check if the first request for the HTML file has the "connection-keepalive" field in its header? If yes, the client probably did not close the connection after loading the page and keeps one socket busy in the W5500.

stevestrong
Posts: 1435
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Ethernet_STM + W5500: maximum parallel connections from same client

Post by stevestrong » Thu Jan 05, 2017 9:19 pm

Good point.
But even if it would be so, it should still have plenty of free sockets till 8, shouldnt it?

User avatar
Squonk42
Posts: 63
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France

Re: Ethernet_STM + W5500: maximum parallel connections from same client

Post by Squonk42 » Thu Jan 05, 2017 9:45 pm

That was just a guess...

Do you run as a DHCP client, maybe? That may also eat up another precious socket...

I suggest that you dump the status of each socket (Sn_SR register) to find out if this problem comes from left-over sockets.

User avatar
Squonk42
Posts: 63
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France

Re: Ethernet_STM + W5500: maximum parallel connections from same client

Post by Squonk42 » Thu Jan 05, 2017 10:02 pm

Here is a short dump-all-W5500-registers function:

Code: Select all

void WIZCHIP_DUMP(void)
{
    int i, j;

    printf("\nCommon Register Block:\n");
    for (i = MR; i <= VERSIONR; i += 256) {
        printf("%02x ", WIZCHIP_READ(i));
        if ((i & 0xf00) == (15 * 256)) {
            printf("\n");
        }
    }
    for (j = 0, j < 8, j++) {
        printf("\nSocket %d Register Block:\n", j);
        for (i = Sn_MR(j); i <= Sn_KPALVTR(j); i += 256) {
            printf("%02x ", WIZCHIP_READ(i));
            if ((i & 0xf00) == (15 * 256)) {
                printf("\n");
            }
        }
        printf("\n");
    }
}

stevestrong
Posts: 1435
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Ethernet_STM + W5500: maximum parallel connections from same client

Post by stevestrong » Thu Jan 05, 2017 11:29 pm

Well, it seems that the entire TCP access goes through one socket, all others are free.
So there is not an unavailable socket problem.

Only up to 4 simultaneous requests over one socket are currently possible... Is this maybe limited by the W5500 hardware?
Or is my W5500 chip "tired"?

User avatar
RogerClark
Posts: 6345
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Ethernet_STM + W5500: maximum parallel connections from same client

Post by RogerClark » Fri Jan 06, 2017 3:06 am

Modern browsers do all sorts of tricks to improve download speed, and can simultaneously open loads of connections ;-(

This is not a solution, but try a different browser, I recall a similar issue on the ESP8266 where it would work fine on Internet Explorer but wouldn't work correctly on Chrome. As it may shed some light on the problem.

User avatar
Squonk42
Posts: 63
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France

Re: Ethernet_STM + W5500: maximum parallel connections from same client

Post by Squonk42 » Fri Jan 06, 2017 5:51 am

stevestrong wrote:Well, it seems that the entire TCP access goes through one socket, all others are free.
So there is not an unavailable socket problem.

Only up to 4 simultaneous requests over one socket are currently possible... Is this maybe limited by the W5500 hardware?
Or is my W5500 chip "tired"?
This definitely means that your browser is using connection keepalive in order to cut down the TCP handshake overhead to a single one for all its requests.

The only limit that the W5500 will have is the FIFO size (default'to 2KB. You can raise it to max 16 KB if using a single socket). For it, the traffic using connection keepalive will look like a single stream.

What avout your server? Is it able to handle all these requests simultaneously?

If you have a chance, I suggest sniffing with Wireshark, and using rhe "Follow TCP stream" analysis tool.

stevestrong
Posts: 1435
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Ethernet_STM + W5500: maximum parallel connections from same client

Post by stevestrong » Fri Jan 06, 2017 10:15 am

I don't think that the "Connection live" header tag is parsed by the W5500 chip.
My server is replying with "connection close", but still, you are right, the connection may be kept alive by the browser.

I tried with Firefox, it is better in the way that FF waits till end of HTML load, and requests the asserted images only afterwards. Means that at that moment there are 4 available "pipelines" for requests so that all 4 images are loaded. I have to try a HTML page with 5 images to see how the browser behaves.

Anyway, my server is not able to do multitasking. Meaning that only one request is served at a time.
But the problem is with issuing (or accepting?) more than 4 requests simultaneously. This seems to be somehow the limitation.

Here a snapshot of the server log output:

Code: Select all

Current date and time: 17-01-06 11:17:05
---> request from: 192.168.100.51
--- Socket status ---
Socket 0 is ESTABLISHED, port: 80, D: 192.168.100.51(58222), RX: 420
Socket 1 is LISTEN, port: 80, D: 192.168.100.1(123), RX: 0
Socket 2 is CLOSED, port: 80, D: 192.168.100.51(57950), RX: 0
Socket 3 is CLOSED, port: 80, D: 192.168.100.51(58096), RX: 0
GET /web/index.htm HTTP/1.1
Checking request: web/index.htm
...processed in: 259
--- Socket status ---
Socket 0 is ESTABLISHED, port: 80, D: 192.168.100.51(58222), RX: 0
Socket 1 is ESTABLISHED, port: 80, D: 192.168.100.51(58223), RX: 371
Socket 2 is CLOSED, port: 80, D: 192.168.100.51(57950), RX: 0
Socket 3 is CLOSED, port: 80, D: 192.168.100.51(58096), RX: 0
<--- client end.
Current date and time: 17-01-06 11:17:05
---> request from: 192.168.100.51
--- Socket status ---
Socket 0 is LISTEN, port: 80, D: 192.168.100.51(58222), RX: 0
Socket 1 is ESTABLISHED, port: 80, D: 192.168.100.51(58223), RX: 371
Socket 2 is CLOSED, port: 80, D: 192.168.100.51(57950), RX: 0
Socket 3 is CLOSED, port: 80, D: 192.168.100.51(58096), RX: 0
GET /web/img/backgrnd.png HTTP/1.1
Checking request: web/img/backgrnd.png
...processed in: 596
--- Socket status ---
Socket 0 is ESTABLISHED, port: 80, D: 192.168.100.51(58224), RX: 370
Socket 1 is ESTABLISHED, port: 80, D: 192.168.100.51(58223), RX: 0
Socket 2 is CLOSED, port: 80, D: 192.168.100.51(57950), RX: 0
Socket 3 is CLOSED, port: 80, D: 192.168.100.51(58096), RX: 0
<--- client end.
Current date and time: 17-01-06 11:17:06
---> request from: 192.168.100.51
--- Socket status ---
Socket 0 is ESTABLISHED, port: 80, D: 192.168.100.51(58224), RX: 370
Socket 1 is LISTEN, port: 80, D: 192.168.100.51(58223), RX: 0
Socket 2 is CLOSED, port: 80, D: 192.168.100.51(57950), RX: 0
Socket 3 is CLOSED, port: 80, D: 192.168.100.51(58096), RX: 0
GET /web/img/pump-on.png HTTP/1.1
Checking request: web/img/pump-on.png
...processed in: 35
--- Socket status ---
Socket 0 is ESTABLISHED, port: 80, D: 192.168.100.51(58224), RX: 0
Socket 1 is LISTEN, port: 80, D: 192.168.100.51(58223), RX: 0
Socket 2 is CLOSED, port: 80, D: 192.168.100.51(57950), RX: 0
Socket 3 is CLOSED, port: 80, D: 192.168.100.51(58096), RX: 0
<--- client end.
Current date and time: 17-01-06 11:17:06
---> request from: 192.168.100.51
--- Socket status ---
Socket 0 is LISTEN, port: 80, D: 192.168.100.51(58224), RX: 0
Socket 1 is ESTABLISHED, port: 80, D: 192.168.100.51(58225), RX: 365
Socket 2 is CLOSED, port: 80, D: 192.168.100.51(57950), RX: 0
Socket 3 is CLOSED, port: 80, D: 192.168.100.51(58096), RX: 0
GET /web/img/ww.png HTTP/1.1
Checking request: web/img/ww.png
...processed in: 27
--- Socket status ---
Socket 0 is LISTEN, port: 80, D: 192.168.100.51(58224), RX: 0
Socket 1 is ESTABLISHED, port: 80, D: 192.168.100.51(58225), RX: 0
Socket 2 is CLOSED, port: 80, D: 192.168.100.51(57950), RX: 0
Socket 3 is CLOSED, port: 80, D: 192.168.100.51(58096), RX: 0
<--- client end.
One can see that sockets 0 and 1 are alternatively used, sockets 2 and upwards are not implied in this case.
This also means that the sockets are closed after serving the respective request.
Still, the 4th image "compress.png" is not accepted as request...
W5500_network_1.jpg
W5500_network_1.jpg (67.87 KiB) Viewed 654 times
Last edited by stevestrong on Fri Jan 06, 2017 11:34 pm, edited 1 time in total.

User avatar
ddrown
Posts: 132
Joined: Sat Jan 09, 2016 4:49 am

Re: Ethernet_STM + W5500: maximum parallel connections from same client

Post by ddrown » Fri Jan 06, 2017 4:35 pm

--- Socket status ---
Socket 0 is ESTABLISHED, port: 80, D: 192.168.100.51(58222), RX: 0
Socket 1 is ESTABLISHED, port: 80, D: 192.168.100.51(58223), RX: 371
Socket 2 is CLOSED, port: 80, D: 192.168.100.51(57950), RX: 0
Socket 3 is CLOSED, port: 80, D: 192.168.100.51(58096), RX: 0
<--- client end.
After a brief look through the wiznet code, it seems like their socket API differs from the Unix socket API in one important way: Listening sockets are not held open after accepting a connection. From the paste above, it looks like you wouldn't accept another connection on port 80 because none of your sockets are in LISTEN state. This is probably a race condition between accepting a connection and the library calling EthernetServer::begin() to open a new listening socket.

I think I have a wiznet ethernet shield at home, I should experiment with it some.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest