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
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Daniel-Constantin Mierla -
Michael Ulitskiy