From: Simon P. <sim...@th...> - 2005-04-27 15:35:26
|
Simon Poole wrote: > 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). > And here's the patch that implements this behaviour. It requires my earlier patch from this thread to be applied first (ecore-0.9.9.004-ecore_con-newlists.patch). Comments please. To use, call ecore_con_server_client_limit_set(...), usually straight after ecore_con_server_add(...). All is explained in the code: /** * Sets a limit on the number of clients that can be handled concurrently * by the given server, and a policy on what to do if excess clients try to * connect. * Beware that if you set this once ecore is already running, you may * already have pending CLIENT_ADD events in your event queue. Those * clients have already connected and will not be affected by this call. * Only clients subsequently trying to connect will be affected. * @param svr The given server. * @param client_limit The maximum number of clients to handle * concurrently. -1 means unlimited (default). 0 * effectively disables the server. * @param reject_excess_clients Set to 1 to automatically disconnect * excess clients as soon as they connect if you are * already handling client_limit clients. Set to 0 * (default) to just hold off on the "accept()" * system call until the number of active clients * drops. This causes the kernel to queue up to 4096 * connections (or your kernel's limit, whichever is * lower). * @ingroup Ecore_Con_Server_Group */ void ecore_con_server_client_limit_set(Ecore_Con_Server *svr, int client_limit, char reject_excess_clients); -- Simon Poole www.appliancestudio.com |