Andrei Pelinescu-Onciul schrieb:
[crossposting since this is of general interest]
On Nov 12, 2008 at 00:30, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi Miklos!
This sounds great. Can you make a sample function which uses the new feature?
We are thinking of doing a dns_prefetch module using this. The sip-router.cfg will look like:
route{ ... dns_prefetch("uri", ROUTE_DNS_OK); # end of script }
route[ROUTE_DNS_OK]{ if (dns_error){ ... } # continue normal processing # the uri was resolved and is in the dns cache ... t_relay() ... }
Ok. I see.
However don't expect something quickly as everybody is quite busy and we would still need to write a dns resolver process pool (time consuming).
I still wonder if the DNS resolver in ser is really a good idea. For example if you take a look at bind, it is really mature and still they fix several issues with each release - and doing all the tricks to avoid cache poisoning and handling DNSSEC correctly is not easy. Thus, maybe having a DNS cache in ser can make sense, but having a full resolver IMO not.
Can this also be used for DNS lookups and TCP/TLS connection setup?
Yes for DNS (see above) and in general for any route-level async processing involving tm (e.g. lookup some part of the message in a slow DB and execute automatically another route when the DB responds).
It cannot be used for TCP/TLS, but it's not needed anyway. In ser TCP connection setup and TCP send is already asynchronous, at least if you have tcp_buf_write=yes in ser.cfg (I agree it's not a very well
Interesting. Is it really completely asynchronous with any blocking, or is it handed over to a dedicated "TCP send" process which is then blocked?
(BTW: most of the core new options documentation in ser can be found in NEWS)
Probably this should be merged too.
thanks klaus