[Kamailio-Devel] [Serdev] CVS:commitlog: sip_router/modules/tm t_cancel.c t_fwd.c t_reply.c t_reply.h t_suspend.c t_suspend.h tm.c tm_load.c tm_load.h

[Miklos Tirpak]

Hi Klaus,

regarding your original question, you are right, I have not documented 
the functions yet. I will add the doc to the devel section of the readme 
as soon as I will have some time.

I also have a small module that I was testing with, I can also commit 
this module if you wish as a sample. There is no real functionality in 
the module, it only suspends the transaction for some seconds, and when 
the timer fires, the transaction continues. It is not even good for 
performance testing, because there is a single timer process that calls 
t_continue() for all the transactions. As Andrei wrote, writing a real 
async function would take more time, this was only a baby step.

Regards,
Miklos

On 11/12/2008 11:16 AM, Andrei Pelinescu-Onciul wrote:
> On Nov 12, 2008 at 10:33, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
>>
>> Andrei Pelinescu-Onciul schrieb:
>>> [crossposting since this is of general interest]
>>>
>>> On Nov 12, 2008 at 00:30, Klaus Darilion <klaus.mailinglists at 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.
> 
> Sorry for the name, I was not talking about a full resolver.
> The DNS cache uses in fact a minimalistic resolver. We would just need to
> replace res_search with a res_mkquery and then "manually" send the
> request and wait for an answer in a poll() loop (we won't actually use 
> poll, but the io_wait.h optimized stuff that uses epoll(), kqueue() a.s.o
>  depending on the system).
> We don't need a recursive resolver, we only need something minimal.
> One should still use a close DNS server since the internal resolver does
> not support recursive queries, DNSSEC a.s.o (we could add them, but so
> far there would be little benefit).
> 
>>>> 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?
> 
> Yes, it's completely asynchronous, no process is blocked.
> A brief description on how it's working for send on an already opened
> connection:
>  - check if the connection has data buffered. If it does it means that
>  either is still connecting or a previous send failed to be executed
>  in-place and queued the data => add to the queued data, return.
>  - if no data buffered try non-blocking send. If it fails queue data
>  to the ser internal tcp connection structure and enable waiting for
>  POLLOUT events (socket send buffer has enough space). return.
> 
> For connect is similar: connect() non blocking, queue data, return.
> 
> When a socket can be written, the main tcp process will write the queued
> data (or as much as possible from it).
>  - 
>>> (BTW: most of the core new options documentation in ser can be found
>>> in NEWS)
>> Probably this should be merged too.
> 
> Yes.
> 
> Andrei