Re: [E-devel] Blocking name resolution...
On Wed, 19 Mar 2003 14:46:12 +1000 pchunt <[EMAIL PROTECTED]> babbled: > Carsten Haitzler (The Rasterman) wrote: > > >now if we go fork... do we fork for every dns lookup? for fork once per app? > >just leave the forked child around "in case" we need it? do we institute a > >system-wide dns helper daemon that u set up a local connection to? lots of > >questions... many possible answers... who wants to discuss more? > > > Sorry if this is getting annoying I'm genuinely interested. > > I would favor having the system-wide dns daemon or pool of worker > threads which you IPC'd requests to if this facility is to be heaviliy > used. They could generate events upon completion or reply back across > the same mechanism you sent the request through (Assuming it had 2 way > capability.) > > Does ecore provide any abstracted method of 2 way IPC? that is EXACTLY what i'm working on. ecore_con is the module in ecore that does "connections". it can do local unix socket ones (no dns lookup at all) and now remote (tcp/ip) - and thats the problem i'm solving. i have the stubs of ecore_ipc module that wraps ecore_con a little and parses data coming from a client (or server) into request chunks and removes all the formatting info and just gives you an ipc request major & minor number and the payload data for that request (can be of any size). this is just stubs, but being worked on. it would be possible to produce a "dns helper" daemon in a few dozen lines of code though... especially once i finish off ecore_ipc. the question is - is this the way to go? or something else? -- --- Codito, ergo sum - "I code, therefore I am" The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] [EMAIL PROTECTED] Mobile Phone: +61 (0)413 451 899Home Phone: 02 9698 8615 --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Blocking name resolution...
On Tue, 18 Mar 2003 22:05:19 +1000 pchunt <[EMAIL PROTECTED]> babbled: > > > thar be tcp/ip support in ecore_con now... you can connect to any machine to > > any port.. anywhere or advertise a service on any port... and get clients > > connecting... :) it works! only 1 things that really pisses me off.. the > > blocking gethostbyname(). i don't like that one little bit. i might want to > > add client count limits for services and disconnect error codes in > > disconnect events etc. but that doesnt bother me like the blocking > > gethostbyname() > > > Have you considered using another name resolving library. I believe > libares gives you the ability to resolve names concurrently with other > processes as well as customizing the lookup timeout etc. yes i have. there's adns ( http://www.chiark.greenend.org.uk/~ian/adns/ ), but it's GPL 9not LGPL) and thus we can't go using it. it's also "yet another requirement". i could try using libresolv, but this isn't portable at all. so far the infrastructure is thereto allow for asynchronous connects. a connect attempt will ALWAYS return a server handle. you can even start writing data to it, BUT it will be buffered and not sent until the connect is successful. When the connect succeeds, then an event will be produced - a "ECORE_CON_EVENT_SERVER_ADD" will be sent to the program indicating from then on it has a successful connect to a server and all data will be flushed if there is any data pending to be written. if the connect fails a "ECORE_CON_EVENT_SERVER_DEL" will be produced indicating a loss of a server connection (in this case the connect failed). during this time between the beginning of the connect and the success an asynchronous dns lookup could be done too which would further extend the time until the connect event is received, but will let the program continue on running and responding to user events and other requests. when the dns lookup succeeds he rest of the connect can be done, or if it fails the "ECORE_CON_EVENT_SERVER_DEL" event can happen. this si all quite feasible - the only question is how to do the asynchronous lookup. i'm currently tempted to "do it myself" by writing my own UDP dns request packet and waiting for a reply. the problem is i wont handle tcp mode then... dns requests via udp are fairly straightforward it seems. its doing tcpmode etc. and also doing all the /etc/resolv.conf, /etc/hosts and /etc/nsswitch.conf stuff right (and working on all platforms) thats a bit of trouble. now if we go fork... do we fork for every dns lookup? for fork once per app? just leave the forked child around "in case" we need it? do we institute a system-wide dns helper daemon that u set up a local connection to? lots of questions... many possible answers... who wants to discuss more? -- --- Codito, ergo sum - "I code, therefore I am" The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] [EMAIL PROTECTED] Mobile Phone: +61 (0)413 451 899Home Phone: 02 9698 8615 --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Blocking name resolution...
On Tue, 18 Mar 2003 10:34:27 CST, Ibukun Olumuyiwa <[EMAIL PROTECTED]> said: > Non-blocking name resolution would require > - At least one fork() Or good thread support. Or (for some applications) careful design of the event loop around a select(). pgp0.pgp Description: PGP signature
Re: [E-devel] Blocking name resolution...
On Tue 18 Mar 2003, pchunt wrote: > > >thar be tcp/ip support in ecore_con now... you can connect to any machine > >to > >any port.. anywhere or advertise a service on any port... and get clients > >connecting... :) it works! only 1 things that really pisses me off.. the > >blocking gethostbyname(). i don't like that one little bit. i might want to > >add client count limits for services and disconnect error codes in > >disconnect > >events etc. but that doesnt bother me like the blocking gethostbyname() > > > Have you considered using another name resolving library. I believe > libares gives you the ability to resolve names concurrently with other > processes as well as customizing the lookup timeout etc. > > - pchunt > Non-blocking name resolution would require - At least one fork() - For ecore to be able to respond to other events (especially timers) while waiting for a name resolution >From what I see we will definitely need to make the name resolution "event-based", meaning that you send the request and then go back into the ecore event loop until a "complete" event is generated, and then go ahead and finish the server_connect function. But then server_connect should not return to the calling program ideally until it is complete, so all of this has to be done within ecore. So my idea is a forked name resolution process that will require some IPC within ecore. In any case, it's probably a good idea to stick with standard libraries and thus eliminate extra dependencies and the associated licensing issues. -- | /*\ Ibukun Olumuyiwa | \ / Join the ASCII Ribbon Campaign http://xcomputerman.com| X against HTML mail today! | / \ --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Blocking name resolution...
thar be tcp/ip support in ecore_con now... you can connect to any machine to any port.. anywhere or advertise a service on any port... and get clients connecting... :) it works! only 1 things that really pisses me off.. the blocking gethostbyname(). i don't like that one little bit. i might want to add client count limits for services and disconnect error codes in disconnect events etc. but that doesnt bother me like the blocking gethostbyname() Have you considered using another name resolving library. I believe libares gives you the ability to resolve names concurrently with other processes as well as customizing the lookup timeout etc. - pchunt --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
