-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
non-blocking socket select #10932
Comments
Do you have |
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. |
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. |
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? |
There are many solution here:
|
Okay, thank you very much |
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.The text was updated successfully, but these errors were encountered: