5-socket limit on Pico as well?

[skyguy]

Anyone know where the limit of 5 sockets originates from?

I came across it on the ESP8266, but I thought it was due to the limited RAM. Now I find that 5 is the limit on the Pico W as well :

`
MPY: soft reboot
MicroPython v1.21.0 on 2023-10-06; Raspberry Pi Pico W with RP2040
Type "help()" for more information.

import socket
s1=socket.socket()
s2=socket.socket()
s3=socket.socket()
s4=socket.socket()
s5=socket.socket()
s6=socket.socket()
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 12] ENOMEM
`

I have 12 LED's on my network monitor I'd like to activate simultaneously... :-)

[jimmo]

In lwip/opt.h

/**
 * MEMP_NUM_TCP_PCB: the number of simultaneously active TCP connections.
 * (requires the LWIP_TCP option)
 */
#if !defined MEMP_NUM_TCP_PCB || defined __DOXYGEN__
#define MEMP_NUM_TCP_PCB                5
#endif

You can override this if you build your own firmware by adding it to ports/rp2/lwip_inc/lwipopts.h

[skyguy]

Thanks for that - if I can't work around the limit I'll try a custom firmware.

Am I correct in thinking that increasing the number will reserve more RAM for buffers, thus reducing the available RAM for applications?

[jimmo]

That's right. These buffers are allocated in .bss, and MicroPython uses whatever is left to make its heap.

[Gadgetoid]

Looking into this, making the associated change and noticing that a TCP socket has a fixed RAM cost of about 196 bytes is there any reason we couldn't raise this to 10 or 20 sockets on Pico W/Pico 2 W?

I found that using keepalives and holding sockets open for API requests saves the periodic 300-400ms blocking calls needed to negotiate TLS, but when you're holding sockets open for multiple APIs you run out pretty quickly.

Granted I think most people run into this limit because they forgot to call .close(), a problem I'm attempting to alleviate separately. This five socket limitation isn't well surfaced to users and the resulting "ENOMEM" is technically accurate if we're being pedantic but also completely useless when you're rocking 8MB PSRAM and scratching your head wondering how your board can't find enough RAM to open a socket.

[projectgus]

Looking into this, making the associated change and noticing that a TCP socket has a fixed RAM cost of about 196 bytes is there any reason we couldn't raise this to 10 or 20 sockets on Pico W/Pico 2 W?

I think we could increase this a little, but for 10 or 20 sockets we're talking +1000 or +1500 bytes of static RAM usage which is enough to potentially noticed. It's unfortunate the number is statically defined, because - as you rightly point out - on a board with PSRAM the extra RAM usage would be totally acceptable.

Would 8 be useful for your purposes? That feels to me like a trade-off that would be easier to justify.

Granted I think most people run into this limit because they forgot to call .close(), a problem I'm attempting to alleviate separately.

You're probably thinking of something similar, but we have code in the esp32 port that calls gc_collect() to clean up any abandoned sockets and then tries again:
https://github.com/micropython/micropython/blob/master/ports/esp32/modsocket.c#L297

This would be very good to support on the bare metal LWIP ports, as well.