Re: [reSIProcate] [reSIProcate-commit] resiprocate 9206 bcampen: Two changes that were somewhat tangled together, since they both used the same
Hi Aron,
I suspect you are referring to DUM's behaviour. The changes Byron committed below are all to the core stack only. When you say NIT REFER's - do you mean REFER's that are outside of an INVITE dialog (ie. Out-of-Dialog REFERs)?
Scott
On Sun, Jun 26, 2011 at 11:27 PM, Aron Rosenberg
<arosenberg@xxxxxxxxxxxx> wrote:
Byron,
Does this change make it any easier to consistently be able to access the NIT "request" SipMessage when processing a NIT "response"? Right now, when dealing with NIT REFER's, if the REFER gets 4xx'ed, there is no easy way that I can figure out to access the original Request so that we can extract the original ReferTo header.
-Aron
Aron Rosenberg
Sr. Director, Engineering,
LifeSize, a division of Logitech
On Sat, Jun 25, 2011 at 1:14 PM,
<svn@xxxxxxxxxxxxxxx> wrote:
| Project | resiprocate |
|---|
| New Revision | 9206 |
|---|
| Committer | bcampen (Byron Campen) |
|---|
| Date | 2011-06-25 15:14:49 -0500 (Sat, 25 Jun 2011) |
|---|
Log
Two changes that were somewhat tangled together, since they both used the same
refactoring of the Transport SendData code.
1) State shedding modifications to TransactionState
In a number of cases, we were preserving state (in the form of SipMessages
and DnsResults) in cases where we did not really need them any more. For
example, once we have transmitted a response, there is no need
to preserve the full SipMessage for this response (the raw retransmit buffer
is sufficient). Also, INVITE requests do not need to be maintained once
a final response comes in (since there is no possibility that we'll need to
send a simulated 408 or 503 to the TU, nor will we need to construct a CANCEL
request using the INVITE, nor will we need to retransmit). Similarly, once we
have received a final response for a NIT transaction, we no longer need to
maintain the original request or the retransmit buffer. Lastly, if we are
using a reliable transport, we do not need to maintain retransmit buffers
(although we may need to maintain full original requests for simulated
responses and such).
This change has basically no impact on reliable NIT performance, but a huge
impact on non-reliable and INVITE performance. Prior to this change, either
NIT UDP or INVITE TCP testStack would exhaust main memory on my laptop (with
4GB of main memory), bringing progress to a complete halt on runs longer than
15 seconds or so. I did not bother trying INVITE UDP, but that works now too.
2) Reduction in buffer reallocations while encoding a SipMessage
TransportSelector 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 google
malloc, but a larger difference when linked against OS X's (horrible) standard
malloc.
Modified:
_______________________________________________
resiprocate-commit mailing list
resiprocate-commit@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-commit
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel