Open gli-spirent opened 5 years ago
@gli-spirent For the CoAP server in the develop branch, epoll support is now available, the accessible resources (urls) are hashed and any existing session lookup is now hashed to handle the next incoming packet. Major steps forward since you raised this question.
As it happens, a single socket is needed for receiving traffic to a specific server port (2 for both tcp and udp), no matter how many clients there are talking to that port.
Each client will have an associated 5 tuple session (giving 100K+ sessions in your case) - this is a hashed lookup and if that fails, the new session setup is slow and may currently involve a large linear lookup.
The oddly named coap_write() function (a better name would be coap_io_prepare()) which is called by coap_run_once() also does a linear scan of all the sessions to see if sessions need to be timed out, packets transmitted etc.
Future work is likely on speeding up the new session creation logic by making the sessions also a least recently used (actually the next entries to be timed out) list, which will also speed up the coap_write() logic.
Did anyone do a scale test on server based on libcoap? The endpoint and session used list. The scalilibitly might be a problem.
I'm wondering if I could make a server to support 100K or more clients at the same time. coap_run_once supports 64 sockets at the same time and used select. I guess I need epoll, right?