non-blocking socket select

[xiaotailang]

Hello everyone, I have noticed an issue while using socket for multiplexing. I wrote a server program based on non-blocking sockets and select. However, when I tried to connect to the server using a telnet client, I found that the connection was immediately closed. To investigate this matter, I examined the provided example poll_main.c from the system. I discovered that the example, when using select on non-blocking sockets, can successfully send and receive data with telnet without experiencing immediate disconnection. Upon careful examination of the code in the example, I noticed a difference compared to my implementation. In my code, I first called select to listen for the socket file descriptor and then used accept to accept the incoming connection request. However, in the system's example, they first called accept to handle a connection request and then used select to listen. I would like to know if it is necessary to follow the example's approach when using select in the system. Is it also possible, similar to standard Linux behavior, to use select first and then accept? In my implementation where select is called before accept, the telnet client returns 'connection closed by foreign host' when the connection is terminated.

[pkarashchenko]

Do you have CONFIG_NET_TCPBACKLOG enabled in your test?

[xiaoxiang781216]

it's a very minor implementation issue, I don't believe that the spec defines the behavior in this particular case. So, I would suggest to follow other OS's behavior to make NuttX more compatible with other implementation.

[xiaotailang]

Thank you very much for your kind assistance. Upon a further review, I found that if the CONFIG_NET_TCPBACKLOG is enabled, the corresponding logic is to first select and then accept. However, there seems to be some additional processing involved, so I plan to study the specific implementation and conduct tests accordingly. Once again, I appreciate the helpful responses from the community.

[xiaotailang]

Thank you very much for your previous response. After opening tcpbacklog, I was able to listen to connections normally. I have studied that, by default, the maximum number of connections supported is only 8. If I have dozens, hundreds, or even more connections, do I need to implement multi-threading, thread pools, connection pools, or similar techniques at the application level to support multiple connections like this?

[xiaoxiang781216]

There are many solution here:

1. one thread per connection
2. one thread + poll/select
3. libuv

[xiaotailang]

Okay, thank you very much