Re: [E-devel] ecore_con: limit connections?

[Carsten H. (T. R. <ra...@ra...>]

On Tue, 26 Apr 2005 16:13:38 +0100 Simon Poole <sim...@th...> babbled:

> I am beginning to use Ecore in an embedded-device application, and using 
> ecore_con to implement a TCP server.
> 
> The nature of the application and the resource limitations of the device 
> mean that I can only afford to service one client at a time.  In a 
> traditional Unix server, I would accomplish this by not forking for each 
> incoming connection, and not calling accept() again until I have 
> finished servicing the previous connection.   I could then rely on the 
> TCP subsystem to queue incoming connections for me.

THAT limited? or is the nature of the servicing itself very heavy (eg xferring lots of encoded video data) etc.?

> I'm struggling to understand the sequence of events in 
> _ecore_main_loop_iterate_internal clearly enough to work out if there is 
> a way of using Ecore_Con that acheives this effect?  I think there 
> isn't, but I may be wrong.

ok - ecore_con accepts everyone. it's a very friendly little fellow. very accepting. it's up to you what you do. it wont fork per child - it kind of expects the app to multi-task itself here. whenever a new clients gets accepted you get a new event ECORE_CON_CLIENT_ADD - this gives you the client handle, and you may choose at this point what to do. you can delete the client (ecore_con_client_del()) to instantly disconnect it - or you could simply queue it. it ends up just a client handle. it will read data sent and give it to you - but you can choose to just ignore it for a while, or whatever you please. there is no control on ecore_con in handling accepts as ecore is a "batching system" that does things in stages in a pipeline. basically it will sit in select() waiting for a timeout or for data to wake it up on an fd.

in the case of clients trying to connect the fd for the listening socket will wake up and then ecore_con will do some accepts - as many as needed to accept all current clients. it generates client structures and stores them then generates client add events and puts them in a queue. it will keep running along handling any other fd data that needs handling, timeouts that may have now expired etc. THEN it gets to processing the event queue - where it loops over it calling callbacks registered for that event type. this does end up quite efficient as it promoted batching and it allows code to batch process stuff easily and even easily weed out pointless operations (move X to A, move X to B in sequence can (depending on the semantics of the system) be compressed to: move X to B as its time spent in A is of no consequence (assuming the nature of the task can allow this) - eg mouse move events work quite well as u really are interested in the latest position - and position on certain boundaries (enter and leave) but if you are "too slow" to read the 200 move events in the middle - then you need to play catch up by skipping events).

> If there isn't, then would a patch of the following nature do the trick?
> 1. Add field "char allow_concurrent_connections : 1;" to 
> _Ecore_Con_Server (ecore_con_private.h)

sure - or add a client count limiter as well. the problem with this is ecore_con will still accept connections until control is in your callbacks so it may accept 2 or 3 clients if they connect at the same time. the intent of the client_add events was to allow filtering by instant disconnection ot by some form of authentication (anonymous clients may now be disconnected and authenticated ones kept). 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). sooner or later clients will not be accepted anymore by the kernel either. the question is - where do you want this control?

> 2. At the start of ecore_con_svr_handler (ecore_con.c), if 
> allow_concurrent_connections==0 and the svr->clients list is not empty, 
> return without calling accept().

kind of a subset of the above :)

> If I get confirmation that this isn't currently supported and this patch 
> will work, then I will code and submit...

indeed it would work. unless u are happy to accept then disconnect (clients then KNOW the server is too busy) whereas not accepting a client has no idea whats going on... :)

btw - sounds like you are working on something interesting. i assume you can't share the gory details? :)

> --
> Simon Poole
> www.appliancestudio.com
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> enlightenment-devel mailing list
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...
裸好多                              ra...@de...
Tokyo, Japan (東京 日本)