From: Simon P. <sim...@th...> - 2005-04-27 12:23:42
|
Carsten Haitzler (The Rasterman) wrote: > i would make 2 flags. 1. a client count limiter ( negative == > unlimited, 0 == too busy to accept any clients atm, 1+ == max number > of concurrent clients.) and 2. a excess client accept policy. do they > get instantly disconnected by ecore_con, or just ecore_con stops > calling accept() until client count < max client count (thus allowing > the kernel to buffer). Is there a reason why ecore_con still uses the deprecated list stuff? The ecore_list_nodes() function would be handy here. I'll port it across to the new stuff if there's no obvious impediment to doing so. What would be the preferred way to handle the fact that the new list functions don't use void* arguments? Change the type of "clients" in Ecore_Con_Server to be Ecore_List* (from Ecore_Con_Client*)? Or cast explicitly when calling the ecore_list_ functions? > sooner or later clients will not be accepted anymore by the kernel > either. the question is - where do you want this control? I've looked into this. Ecore_Con is calling listen with backlog=4096. This should set the number of kernel-queued connections to 4096 unless the kernel has a lower internal limit. The Linux limit appears to 128, while "man 2 accept" says BSD's may be 5. Both of these limits are entirely acceptable from my applications point of view, and I will document the limitations in the code markup. -- Simon Poole www.appliancestudio.com |