Web request concurrency management

[logicog]

The web-server in RTLPlayground is single-treaded and can only handle 1 concurrent connection. Web-Browsers such as Firefox use up to 6 concurrent connections to a given domain. This will lead to the tcp: found no unused connections showing up in the CLI and timeouts happening in the connections from the browser. While it does not seem possible to control this concurrency for connections for .html and .js files, it is possible to control this behaviour for the xhttp requests done to transfer the status of the ports and the information on the web-pages of the device.

Implement a queueing system for the xhttp requests and control the sequence of .json calls when a page is created.

As can be seen, the calls for status.json and bandwidth.json are now coordinated making them finish in < 40ms. The coordination of the sequence of .json requests at the load of a page makes it possible to reload a page in < 300ms, which appears as if the page loads instantaneously.

Of course, the better solution would be to add further concurrent connections to uIP, making use of a queueing system and possibly the use of interrupt-driven RX, however, in terms of snappiness, the present solution already goes a long way.

This is currently on top of the bandwidth PR, but will become independent once those are merged. This is mostly to start testing and discussion.

[vDorst]

This needs a rebase

[logicog]

Rebased.

[vDorst]

Is seems to break the site.
I am missing the portstatus on the top.

Site now looks like this in Firefox aswell in Brave.

[logicog]

It looks like I forgot to enable the optimized xhttp request flow on some pages, probably because they were still cached when I tested :-( .
I updated the PR.

[vDorst]

thanks

[TylerDurden-23]

It looks like since this PR, the web interface is no longer working reliably:

[logicog]

Unfortunately, the interesting bits in the error message in the screenshot are missing. Could you make a screenshot with the full javascript error, please?

Also, is this Chrome or Firefox?

Could you say, when this appears: does it appear on all web-pages or only on the port statistics page? When you say not reliable: is this reproducible, or random?

[TylerDurden-23]

@logicog This happens in chromium based browsers like edge and brave.
If I set a breakpoint before the error, the page loads correctly, so maybe this is a timing issue.
It happens on all pages and the port state on the top is also not loaded.

[logicog]

Can you cross-check with Firefox, please if this is possible? This was tested on Firefox and it was working there. Maybe this is a browser-compatibility issue. We have issues also with the upload function IIRC.

[TylerDurden-23]

It is working with Firefox - except the port status at the top that never worked with Firefox.
It was working before this change with Chromium browsers.

[logicog]

It is working with Firefox - except the port status at the top that never worked with Firefox.

Can you explain what did not work with Firefox regarding the port status, exactly? Because I was testing with Firefox and for me it was working.

I have Chromium installed and will start testing with that, too.

[TylerDurden-23]

@logicog Firefox can't access & update the embedded SVG as long as the client and the server are in the same subnet.
Seems to be a security enhancement.
Also: This is obvious the most likely scenario for accessing a switch. :)

[logicog]

Firefox can't access & update the embedded SVG as long as the client and the server are in the same subnet.
Seems to be a security enhancement.
Also: This is obvious the most likely scenario for accessing a switch. :)

This works for me. Also for me Firefox and the device are in the same subnet. Can you point me to somewhere, where the problem is described?

[logicog]

This is how it looks for me with Firefox on the same subnet.

[TylerDurden-23]

@logicog Basically this is the problem - for some reason Firefox does not allow access to the SVG object (and hence a null reference is returned):

Firefox seem to treat the SVG as a different origin - I really don't know why though.

[logicog]

My suspicion is that the SVG is not yet loaded, because of some timing issue. Maybe the sequence of loading the image and the json request is somehow different and the assumption is that first the SVG are there and then .json. The syncing is in principle done using the load() event when the html has been loaded. For me this includes also the SVG. Maybe this is not always guaranteed.

[TylerDurden-23]

@logicog Not it is definitely loaded.
For some reason Firefox determines that the Object/SVG is not of the same origin.

Before I allowed loading the port SVG without authentication, it would also redirect to the login page there and not load the SVG at all. Showing that Firefox thinks of the embedded SVG as a different origin.

[logicog]

Before I allowed loading the port SVG without authentication, it would also redirect to the login page there and not load the SVG at all. Showing that Firefox thinks of the embedded SVG as a different origin.

Then I do not understand why it works for me, but also for others who use Firefox. I am using the ESR version of Firefox. Do you use a different one?

[TylerDurden-23]

@logicog 148 ... ESR is 140 I think.

PS: It is working with the ESR version - seems they have changed something after 140.

[logicog]

PS: It is working with the ESR version - seems they have changed something after 140.

Could you investigate? Maybe it is the same issue as for Chrome. And sorry, I keep asking questions, instead of providing answers, I am working in parallel on the management VLAN issue, and I do not make progress...

[logicog]

Can you try PR #167 ? I believe I fixed the issues with both Chrome and latest Firefox.

[TylerDurden-23]

@logicog Looks good, it seems #167 fixed it for firefox > 148 and Chrome based browsers.