On Tue, 18 Mar 2003 22:05:19 +1000 pchunt <[EMAIL PROTECTED]> babbled:
> <quote from 'rastermans' cvs checkin> > > 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() > </quote> > > 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 899 Home 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
