Re: [recon-devel] Thread safe of recon for srtp
Without looking in detail something like that would probably be fine.
There is definately some room for optimization here. I'll put this on
my TODO list.
Scott
2009/1/20 Karlsson <boost.regex@xxxxxxxxx>:
> Now I think there have a way to optimize SRTP feature.
>
> Consider these two points:
>
> 1: Change mSRTPSessionOut and mSRTPSessionIn are not frequent.
> 2: The MediaStream::srtpProtect and MediaStream::srtpUnprotect are called
> very frequent.
>
>
> So I think we can use two mutex: mInboundMutex and mOutboundMutex to
> instead mMutex;
>
>
> a: In MediaStream::createOutboundSRTPSession function:
>
> 1: Delete Lock lock(mMutex);
> 2: Add Lock lock(mOutboundMutex)
>
>
> b: In MediaStream::srtpProtect
>
> 1: Delete Lock lock(mMutex);
> 2: Add Lock lock(mOutboundMutex)
>
>
> c: MediaStream::createInboundSRTPSession
>
> 1: Delete Lock lock(mMutex);
> 2: Add Lock lock(mInboundMutex)
>
>
> d: MediaStream::srtpUnprotect
>
> 1: Delete Lock lock(mMutex);
> 2: Add Lock lock(mInboundMutex)
>
>
>
>
> On Tue, Jan 20, 2009 at 9:35 AM, Karlsson <boost.regex@xxxxxxxxx> wrote:
>>
>> I know it, but for the RTP data, it's base on the UDP, allows packet lost
>> or delay etc...
>> So consider this:
>>
>> 1: A thread now processing send data.
>> 2: B thread change the mSTPSessionOut.
>> 3: A thread process data faild, because the SRTP context changed - then
>> this RTP packet send failed.
>> 4: B thread change the mSRTPSession succeeded
>> 5: A thread process next send data(next RTP packet)
>>
>> In this case just lost one RTP packet(sometime maybe 2-3 RTP packets), but
>> consider change mSRTPSessionOut is not frequent,
>> So I think can move this lock.
>>
>> Thanks
>>
>>
>> On Tue, Jan 20, 2009 at 2:08 AM, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
>>>
>>> The SRTP sessions (ie. mSRTPSessionOut) can change (via
>>> createXXboundSRTPSession) in another thread while sending/receiving is
>>> active – ie. when the SRTP session parameters are re-negotiated via SDP. So
>>> this optimization is not possible.
>>>
>>>
>>>
>>> Scott
>>>
>>>
>>>
>>> From: recon-devel-bounces@xxxxxxxxxxxxxxx
>>> [mailto:recon-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Karlsson
>>> Sent: Monday, January 19, 2009 1:03 PM
>>> To: Scott Godin
>>> Cc: recon-devel@xxxxxxxxxxxxxxx
>>> Subject: Re: [recon-devel] Thread safe of recon for srtp
>>>
>>>
>>>
>>> So I think maybe there can do optimization, likes:
>>>
>>> err_status_t
>>> MediaStream::srtpProtect(void* data, int* size, bool rtcp)
>>> {
>>> {
>>> err_status_t status = err_status_no_ctx;
>>>
>>> Lock lock(mMutex);
>>> if (mSRTPSessionOutCreated == false)
>>> {
>>> return err_status_no_ctx;
>>> }
>>> }
>>>
>>> if(rtcp)
>>> {
>>> status = srtp_protect_rtcp(mSRTPSessionOut, data, size);
>>> }
>>> else
>>> {
>>> status = srtp_protect(mSRTPSessionOut, data, size);
>>> }
>>>
>>> return status;
>>> }
>>>
>>> Because the srtp functions will take long time ?
>>>
>>>
>>> On Tue, Jan 20, 2009 at 1:28 AM, Scott Godin <sgodin@xxxxxxxxxxxxxxx>
>>> wrote:
>>>
>>> That is correct.
>>>
>>> 2009/1/19 Karlsson <boost.regex@xxxxxxxxx>:
>>>
>>> > Hi, I think the libSRTP is thread safe and does not requires mutex,
>>> > why in
>>> > the mediastream.cxx of recon there has a lock ?
>>> > Likes MediaStream::srtpProtect and MediaStream::srtpUnprotect,
>>> > MediaStream::createOutboundSRTPSession etc...
>>> >
>>> > I think this lock is used for mSRTPSessionOutCreated,
>>> > mSRTPSessionInCreated
>>> > and independent the srtp, right ?
>>> >
>>> > Thanks
>>> >
>>>
>>> > _______________________________________________
>>> > recon-devel mailing list
>>> > recon-devel@xxxxxxxxxxxxxxx
>>> > List Archive: http://list.resiprocate.org/archive/recon-devel/
>>> >
>>>
>>>
>
>
> _______________________________________________
> recon-devel mailing list
> recon-devel@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/recon-devel/
>