Does it make sense to allow more than one connection from the same client to a TCP server socket?

[devyte]

This issue is related to this, where a better method of sending payloads over a server socket is being pursued.

A normal sequence for a server socket would be something like this:
connection1 comes in -> onReceive() callback is called -> send() some reply -> onSent() once done

A client can apparently do multiple connections in parallel to a TCP server socket on the ESP, where each connection runs a new instance of the onListen() callback, with all the context it contains.
This means that the following is possible:
connection1 -> onReceive1() -> send1() -> connection2 -> onReceive2() -> send2() -> onSent1() -> onSent2()

The above is simplified. In the httpserver, send()s are actually done in a coroutine, and then immediately after that yield() is called to allow the main thread to actually handle the sending.

The sequence means that a second connection is received before the first connection has a chance to finish and call onSent(), and so the onSent() callback is delayed until later.

The browser (i.e.: chrome) is requesting multiple elements from a webpage served by the ESP in parallel, so for the 2nd connection, the context for the second connection is too much and the ESP croaks.

Given all the other limitations currently in play, does it make sense to allow more than one connection from the same client to a TCP server? or rather, more than one connection to a TCP server, period?

Some more details:
In truth, the coroutine buffers data to be sent up to a threshold (I'm currently testing at 1400). Once the threshold is reached, the data is cut to 1400 and flushed. If the total data is big, as in multiple times the threshold, then the buffered contents and the new data are cut up into chunks of 1400 and sent-flushed in a loop.
What this means in code is that the following sequence is typical, assuming a single connection:
connection -> onReceive() -> send()+yield() -> onSent() -> send()+yield() -> onSent() ... etc ...

The whole context (functions, closures, etc) is really kept until the end where it is released, so if a second connection comes in before the sequence is done, there is a race condition, and a second context could be created -> run out of heap and panic.

If it does makes sense to allow multiple connections, does anyone know of a way to tell the browser to only request one element at a time from the server, that doesn't involve just closing the additional connections?

[TerryE]

The current espconn LWiP implementation allows up to 5 connections per TCP server, though at a espconn API level this is configurable. You can also have multiple outbound connections, again configurable at an espconn API level but the default is also 5 IIRC. There is a strong argument for exposing the ability to vary the maximum number of connections as most browsers will correctly process such refused additional connections and balance requests over the ones allowed.

But as to your Q: Yes, but it should be configurable at a Lua net level.

You should write your app to handle concurrent connections. This isn't a firmware issue. I keep saying: webservers are complicated; even a pretty minimal one is far more complicated than can fit into the Lua execution environment on an esp8266. It's one thing dong something minimal, say to serve a RESTful API, but serving up complex web pages to a modern browser is a whole different ballgame.

[devyte]

@TerryE agreed. Yes, you mentioned somewhere that a webserver on the ESP is abusing it, but like Marcos said recently: let the abuse begin :) I may with some effort reduce mem footprint to allow 2 connections, but I don't think I can get to 5...
Alright, making the max number of connections confiurable via an additional configuration parameter (I'm guessing to net.createServer() or createConnection()?) would make this issue an enhancement. Would you rather I just close it in view of the current stabilization effort, or repurpose it to cover only the additional parameter, or close it and open a new clean one?

[DesperateProgrammer]

I agree, that a http server is stretching the the purpose of the ESP.
Yet I use http myself to be able to setup the device for the enduser by http and provide the information which is needed until a simplier protocol take over (in my case i.e. a Serial Port Server)

To do this, I have written a small http server (attached with a demo as spiffs image), that serves more then just one file (css, images, etc) and it is doing this by concurrently transfering on all connections the browser tries to open.
In the attached image you see two files concurrenly transfered to Firefox.

This is done by sending in chunks without a too high memory footprint. I don't think this would have problems serving all available connection slots.

So yes, it should be possible to have multiple tcp connects.
I agree on TerryE, that making it a configuration accessed by lua will make the most versatile approach.

[Simultaneous HTTP connections] ](https://cloud.githubusercontent.com/assets/16925975/13197564/807d0056-d7f1-11e5-95c7-6c5f8b9a66c6.png)

Spiffs.zip

[TerryE]

Incidentally even if you don't want to use a webserver on your LAN as an application tier (with all of the advantages of the full functionality of Apache2, Nginx, ... including proper security, rich development environment...) then you should at least consider configuring an RPi2 or equiv as in effect a local CDN so that only the main content HTML document comes from the ESP and all of the js, images, css and other furniture is delivered from the RPi2.

[DesperateProgrammer]

Yes for sure, where it's possible,
This assumes you have decent control over the infrastructure.

But really, noone wants to setup another device or webserver just to bootstrap the configuration of a handheld and yet anyone wants it good looking (even if you only use it for 30secs at all)
Given business customers, that might rule the device out on an instant.

[marcelstoer]

Does it make sense to allow more than one connection from the same client to a TCP server socket?

Yes.

Would you rather I just close it in view of the current stabilization effort, or repurpose it to cover only the additional parameter, or close it and open a new clean one?

IMHO you should close it. If you decide you really need the additional parameter your PR may still reference this (closed) issue.

[TerryE]

Marcel, I am going through the net module doing a rewrite and in the process picking up a lot of issues such as the resources leaks and this concurrent connects issue. Even if the consensus is that its too high risk to adopt a rewrite, we should still go through all of the issues that this has thrown up and backport the material ones. I suggest that we leave the net module alone for the next few weeks in the meantime.