12 Nov
2008
12 Nov
'08
11:33 a.m.
Andrei Pelinescu-Onciul schrieb:
Interesting. Is it really completely asynchronous with any blocking, or
is it handed over to a dedicated "TCP send" process which is then blocked?
[crossposting since this is of general interest]
On Nov 12, 2008 at 00:30, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Ok. I see.
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()
...
} 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 (BTW: most of the core new options documentation in
ser can be found
in NEWS)
Probably this should be merged too.
thanks
klaus