< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index |
I have done the test for this change and it works well now.
once receive the 503 response, the dns entry is placed in blacklist, and all other subsequent requests(i.e. INVITE,OPTION) to this dns entry are blocked for the duration retry-after in 503 response specifies.
Thanks
At 2017-03-22 00:44:56, "Scott Godin" <sgodin@xxxxxxxxxxxxxxx> wrote:
Hi Edwin,I see - nice catch! I think we should be moving the if(mDnsResult) block to after the sendToTU call. ie:if (mState == Calling || mState == Proceeding){// MUST pass the received response up to the TU, and the client// transaction MUST generate an ACK request, even if the transport is// reliable, if transport is Unreliable then Fire the Timer D which// take care of re-Transmission of ACKmState = Completed;mController.mTimers.add(Timer::TimerD, mId, Timer::TD ); SipMessage* ack = Helper::makeFailureAck(*mNextTransmission, *sip); mNextTransmission->copyOutboundDecoratorsToStackF ailureAck(*ack); resetNextTransmission(ack);sendCurrentToWire();sendToTU(sip); // don't delete msgif(mDnsResult){mDnsResult->destroy();mDnsResult=0;mPendingOperation=None;}}Can you test this change out, and if everything looks good, I will commit it.Thanks for helping out!ScottOn Tue, Mar 21, 2017 at 9:32 AM, 海滨 <lhb8859138@xxxxxxx> wrote:If we set the mDnsResult as 0 when receive the 503 response for the udp transaction, the dns entry seems never been blacklisted in sendToTu function even though the retry-after value is more than 0. is it reasonable?ThanksEdwin Li
在 2017-03-21 02:36:57,"Scott Godin" <sgodin@sipspectrum.com > wrote:
Here are the check-in notes. Are you seeing a problem with this change?Thanks,Scott* Two changes that were somewhat tangled together, since they both used the samerefactoring of the Transport SendData code.1) State shedding modifications to TransactionStateIn a number of cases, we were preserving state (in the form of SipMessagesand DnsResults) in cases where we did not really need them any more. Forexample, once we have transmitted a response, there is no needto preserve the full SipMessage for this response (the raw retransmit bufferis sufficient). Also, INVITE requests do not need to be maintained oncea final response comes in (since there is no possibility that we'll need tosend a simulated 408 or 503 to the TU, nor will we need to construct a CANCELrequest using the INVITE, nor will we need to retransmit). Similarly, once wehave received a final response for a NIT transaction, we no longer need tomaintain the original request or the retransmit buffer. Lastly, if we areusing a reliable transport, we do not need to maintain retransmit buffers(although we may need to maintain full original requests for simulatedresponses and such).This change has basically no impact on reliable NIT performance, but a hugeimpact on non-reliable and INVITE performance. Prior to this change, eitherNIT UDP or INVITE TCP testStack would exhaust main memory on my laptop (with4GB of main memory), bringing progress to a complete halt on runs longer than15 seconds or so. I did not bother trying INVITE UDP, but that works now too.2) Reduction in buffer reallocations while encoding a SipMessageTransportSelector now keeps a moving average of the outgoing message size,which is used to preallocate the buffers into which SipMessages are encoded.This ends up making a small difference in testStack when linked against googlemalloc, but a larger difference when linked against OS X's (horrible) standardmalloc.On Mon, Mar 20, 2017 at 11:29 AM, 海滨 <lhb8859138@xxxxxxx> wrote:1.10.2: TransactionState.cxx line1322~1327The mDnsResult is set to 0 here, which is different from 1.7.ThanksEdwin Li在 2017-03-19 23:13:53,"Scott Godin" <sgodin@xxxxxxxxxxxxxxx> wrote:
What is the source file and line number?Thanks,ScottOn Sat, Mar 18, 2017 at 8:29 PM, 海滨 <lhb8859138@xxxxxxx> wrote:
Hi all,
Does anyone know why TransactionState set mDnsRestult as 0 when receive the 503 response from wire if mIsReliable=false from release 1.8, instead of blacklist the last result(which is implemented in 1.7)? I can't see any information about this change in the release note.
Thanks
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-de vel
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-de vel