10 Oct
2006
10 Oct
'06
9 p.m.
Daniel,
Please pardon my ignorance, but tm docs are not very clear on the subject. At least for
me.
Could you please elaborate on what is the problem with the code below? My tests (limited
of course
as it's not yet in production) shows it behaves as expected.
Do you see the problems with CANCEL and ACK or with other requests or both?
Also I'd appreciate if you could kindly provide the snippets of correct code.
A while ago I've asked similar questions about CANCELs and ACKs processing:
http://openser.org/pipermail/users/2005-July/000315.html
http://openser.org/pipermail/users/2005-July/000319.html
There was no t_check_trans() function at that moment and also there was a race condition
in CANCEL that AFAIK has been addressed since.
Then solution was to use the following code:
if (is_method("ACK")) {
#absorbs in-transaction hop-by-hop ACKs
#or returns false if this is lost/broken not-in-transaction message
if (t_newtran()) {
#this happens if ACK cannot be matched to transaction due
#to differences in headers (Via,From,...).
xlog("L_NOTICE","is bad or lost. dropping");
}
exit;
}
Full processing logic was applied CANCELs and retransmissions.
Now I would like to extend the same technique to CANCELs and retransmissions if possible.
I think that in case of a moderately heavy processing logic that involves several database
queries
this can provide a noticeable performance win.
Thanks a lot,
Michael
On Tuesday 10 October 2006 03:14 am, Daniel-Constantin Mierla wrote:
t_relay() will absorb the retransmissions, the
drawback is that the
messages is processed through all script to t_relay(). You can use
t_newtran() somewhere at the beginning and then use t_forward_nonack()
instead of t_relay(). Also, relace sl_send_replay() with t_replay(). TM
docs should give you more details about usage of these functions.
Cheers,
Daniel
On 10/09/06 21:07, Michael Ulitskiy wrote:
Hello,
I have a question about a good way to handle retransmissions.
I see that t_check_trans() function is able to tell me if the request is a retransmission
or not.
So my question is: should I apply the whole request-processing logic to retransmissions
or I can simply do something like the following:
if (is_method("ACK|CANCEL")) {
if (t_check_trans()) {
t_relay();
} else {
xlog(L_NOTICE,"$rm: No matching transaction. dropping");
exit;
}
}
if (t_check_trans()) {
xlog(L_NOTICE,"$rm: is a retransmission");
t_relay();
}
I.e. in the above code I assume that t_relay() would be able to match the request
to the transaction and absorb it like it does for ACKs and CANCELs without
applying whatever modification was done to original request.
Is it true?
Thanks,
Michael
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users