Heisann,
I know everyone is busy getting this project off the ground, but I
think it might be worthwhile discussing the future on the side and
anyway, this regards the database API which sort of is currently being
nailed down.
Since we were talking about it internally, I was thinking a bit about
the future of usrloc. It has this thing where it caches entries in
memory. Now, technically usrloc is just a database (or maybe a database
on top of a database). Wouldn't it make sense to get rid of it and
instead implement a database module that caches and then simplify the
registrar module to use database queries directly?
This has the benefit that other modules can suddenly use caching, too,
if they want. In SER, the domain module for instance already does some
caching, so there is some code replication.
I believe the database API to be simple enough to provide caching
especially since the new model with pre-registered queries allows the
cache to be set up with those queries in mind.
Regards,
Martin
[crossposting since this is of general interest]
On Nov 12, 2008 at 00:30, Klaus Darilion <klaus.mailinglists(a)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()
...
}
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).
Note that this is not the "final" async. solution since it's not
transparent for the script writer (scripts would have to be written in a
special way), works only with tm and it's also a little inefficient for
dns usage.
In the long term we will have completely transparent async. support for dns
and maybe db lookups (though it's controversial if we really need it for
normal db lookups). This will take much longer and will require among
other things reviewing all the global variable use (most of the global
variables will either need to be registered or allocated in some known
special place).
If Miklos doesn't beat me to it, I'll probably start working on it only
after the core merging is complete.
>
> 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
chosen name :-)). TLS does not support it yet, so if you use TLS
you should not set this option (that's why it's not yet the default).
TLS support for it requires non-trivial changes in the tcp core and it
will probably come after the merge (it's started already but far from
finished).
(BTW: most of the core new options documentation in ser can be found
in NEWS)
Andrei
>
> Further, also for Kamailio cooperation better documentation would be
> needed. Thus, instead of writing long CVS commit messages I think it
> would be better to write the text into the module documentation, and
> then copy/paste it into the CVS commit.
>
> regards
> Klaus
>
> Miklos Tirpak wrote:
> > tirpi 2008/11/10 13:47:03 CET
> >
> > SER CVS Repository
> >
> > Modified files:
> > modules/tm t_cancel.c t_fwd.c t_reply.c t_reply.h
> > tm.c tm_load.c tm_load.h
> > Added files:
> > modules/tm t_suspend.c t_suspend.h
> > Log:
> > t_suspend() and t_continue() functions are introduced.
> >
> > These fuctions can be used by other modules to implement
> > asynchronous actions: t_suspend() saves the transaction, returns its
> > identifiers, and t_continue() continues the SIP request processing.
> > (The transaction processing does not continue from the same point
> > in the script, a separate route block defined by the parameter of
> > t_continue() is executed instead. The reply lock is held during the
> > route block execution.) FR timer is ticking while the
> > transaction is suspended, and the transaction's failure route is
> > executed if t_continue() is not called in time.
> >
> > Missing: msg lumps are saved by t_suspend() and are not updated by
> > the subsequent t_relay(). This means that the modifications made
> > between them are lost.
> >
> > Revision Changes Path
> > 1.32 +7 -2 sip_router/modules/tm/t_cancel.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_cance…
> > 1.107 +8 -2 sip_router/modules/tm/t_fwd.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_fwd.c…
> > 1.162 +4 -4 sip_router/modules/tm/t_reply.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_reply…
> > 1.31 +7 -1 sip_router/modules/tm/t_reply.h
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_reply…
> > 1.1 +154 -0 sip_router/modules/tm/t_suspend.c (new)
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_suspe…
> > 1.1 +42 -0 sip_router/modules/tm/t_suspend.h (new)
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_suspe…
> > 1.177 +3 -1 sip_router/modules/tm/tm.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm.c.di…
> > 1.31 +11 -1 sip_router/modules/tm/tm_load.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm_load…
> > 1.31 +4 -1 sip_router/modules/tm/tm_load.h
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm_load…
> > _______________________________________________
> > Serdev mailing list
> > Serdev(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serdev
>
> _______________________________________________
> Serdev mailing list
> Serdev(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
Module: sip-router
Branch: andrei/script_vars
Commit: 0b3512af8f5c42bea2e17de6efce9571e85241f8
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0b3512a…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Thu Dec 11 19:30:41 2008 +0100
script engine: more rvalue optimizations
- optimize:
($v * a) * b -> $v * (a * b) if '*' is associative
(a * $v) * b -> (a * b) * $v if '*' is assoc. and commutative
a * ($v * b) -> (a * b) * $v if '*' is assoc. and commutative
a * (b * $v) -> (a * b) * $v if '*' is associative
where a & b are constants, $v is a var (pvar or avp) and '*' is
the operator.
- special hacks for optimizing '+' ('+' is a special case because
in the current form it can work both with strings and ints which
combined with the dynamic typed vars make it very hard to
optimize)
---
rvalue.c | 400 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 366 insertions(+), 34 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=0b3…
Module: sip-router
Branch: andrei/script_vars
Commit: 5219ecb708daba13749ec8d242129a117449ba9f
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5219ecb…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Wed Dec 10 14:52:12 2008 +0100
core: new command line option (debugging)
- new command line option controlling the script optimization
level: -O (e.g. -O0 - no optimizations). By default the
optimization level is set to maximum (2 for now).
- renamed sctp max process number command line option from -O to -Q
---
main.c | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/main.c b/main.c
index 86c7a2f..802e1f0 100644
--- a/main.c
+++ b/main.c
@@ -222,7 +222,7 @@ Options:\n\
#endif
#ifdef USE_SCTP
" -S disable sctp\n\
- -O Number of sctp child processes (default: equal to `-n')\n"
+ -Q Number of sctp child processes (default: equal to `-n')\n"
#endif /* USE_SCTP */
" -V Version number\n\
-h This help message\n\
@@ -234,7 +234,8 @@ Options:\n\
-u uid Change uid \n\
-g gid Change gid \n\
-P file Create a pid file\n\
- -G file Create a pgid file\n"
+ -G file Create a pgid file\n\
+ -O nr Script optimization level (debugging option)\n"
#ifdef STATS
" -s file File to which statistics is dumped (disabled otherwise)\n"
#endif
@@ -1502,7 +1503,7 @@ int main(int argc, char** argv)
"DBG_MSG_QA enabled, ser may exit abruptly\n");
#endif
- options= ":f:cm:dVhEb:l:L:n:vrRDTN:W:w:t:u:g:P:G:SO:"
+ options= ":f:cm:dVhEb:l:L:n:vrRDTN:W:w:t:u:g:P:G:SQ:O:"
#ifdef STATS
"s:"
#endif
@@ -1572,6 +1573,14 @@ int main(int argc, char** argv)
case 'E':
log_stderr=1;
break;
+ case 'O':
+ scr_opt_lev=strtol(optarg, &tmp, 10);
+ if (tmp &&(*tmp)){
+ fprintf(stderr, "bad optimization level: -O %s\n",
+ optarg);
+ goto error;
+ };
+ break;
case 'b':
case 'l':
case 'n':
@@ -1589,7 +1598,7 @@ int main(int argc, char** argv)
case 'P':
case 'G':
case 'S':
- case 'O':
+ case 'Q':
case 's':
break;
case '?':
@@ -1676,6 +1685,7 @@ try_again:
case 'd':
case 'V':
case 'h':
+ case 'O':
break;
case 'E':
log_stderr=1; // use in both getopt switches
@@ -1762,7 +1772,7 @@ try_again:
fprintf(stderr,"WARNING: sctp support not compiled in\n");
#endif
break;
- case 'O':
+ case 'Q':
#ifdef USE_SCTP
sctp_children_no=strtol(optarg, &tmp, 10);
if ((tmp==0) ||(*tmp)){