Feature request: limit WiFiServer backlog size

[douniwan5788]

Please limit the _unclaimed chain as listen backlog (http://man7.org/linux/man-pages/man2/listen.2.html)

Arduino/libraries/ESP8266WiFi/src/WiFiServer.cpp

Lines 164 to 171 in cd05bae

	long WiFiServer::_accept(tcp_pcb* apcb, long err) {
	(void) err;
	DEBUGV("WS:ac\r\n");
	ClientContext* client = new ClientContext(apcb, &WiFiServer::_s_discard, this);
	_unclaimed = slist_append_tail(_unclaimed, client);
	tcp_accepted(_pcb);
	return ERR_OK;
	}

[d-a-v]

This is a very fair request, to prevent DoS and memory filling.
We could use lwIP's tcp_listen_with_backlog (instead of tcp_listen), but it does the same job as the _unclaimed list already implemented by brilliant core developpers. In both case we must limit that number.

What are the issues you are facing ?
What would be a fair amount of maximum backlogged connections with your use case ?
I think a maximum number between 4 and 8 should be sufficient for the general case.
If there are more incoming clients, their tcp stack will have to wait for ESP to effectively accept/honor the previous ones or they will timeout without filling our memory.

Would you make a PR for that ?

I don't think this has any relation with #928, why do you think so ?

[douniwan5788]

This is a very fair request, to prevent DoS and memory filling.
We could use lwIP's tcp_listen_with_backlog (instead of tcp_listen), but it does the same job as the _unclaimed list already implemented by brilliant core developpers. In both case we must limit that number.

What are the issues you are facing ?
What would be a fair amount of maximum backlogged connections with your use case ?
I think a maximum number between 4 and 8 should be sufficient for the general case.
If there are more incoming clients, their tcp stack will have to wait for ESP to effectively accept/honor the previous ones or they will timeout without filling our memory.

Would you make a PR for that ?

I don't think this has any relation with #928, why do you think so ?

Sorry, it has nothing to do with #928, should I delete it? I just encounter with Links2004's post while googling this backlog problem

I am not familiar with Arduino, but if I have free time, I will make a PR.

My issue is arendst/Tasmota#4460

[d-a-v]

Sorry, it has nothing to do with #928, should I delete it?

No worry, I was just asking because you posted at the two places

I am not familiar with Arduino, but if I have free time, I will make a PR.

This will be welcome !

[d-a-v]

Tasmota is currently releasing updates only using arduino core-2.3.0 (AFAIK, until core-2.5.0 is out and has its chances).
#928 issue no longer happens with core-2.4.0 and later when lwIP-v2 is enabled, but the issue you are reporting here is still valid with any version of lwIP.

[devyte]

Pushing back.