The same principles apply to NetX as they do in LWIP or any Sockets interface.
If you want to handle multipl connections concurrently, then after the server calls the equiv of `accept()`
you have to spawn a new thread to handle the communication on that connection. That way, the main thread
can call immediately call listen() again and be ready for a new connection.
In the Echo Server example, after the call to `nx_tcp_server_socket_accept`, the main thread goes into a while(1) loop and talks to the connected client until it disconnects.
There is a "cheat" which may or may not suit your needs. The socket interface usually support a configurable-length "queue" of pending clients. So that if a client tries to connect while the server is dealing with another connection, hey are not refused, they simply block (on their side). If you can guarantee that each client will connect, have a brief exchange with the server, and then disconnect, you can get away with having just one main thread. But be this usually ends up not being good enough. It also isn't resilient to any errors (if a client dies, you server will stall until a timeout occurs, for example, which can be many seconds or even more).
Newer network stacks (in general) use an "event-loop" and an async model of network programming, I don't know if the NetX API supports something like this. These APIs tend to scale better and use less memory (maybe), but there's a learning curve and it can be harder to debug your code.
- If you feel a post has answered your question, please click "Accept as Solution".
- Once you've solved your issue, please consider posting a summary with any additional details you've learned. Your new knowledge may help others in the future.
