Conversation
| } | ||
| } | ||
|
|
||
| DataPacketCryptor::DataPacketCryptor( |
There was a problem hiding this comment.
Hey, I noticed this doesn't use the signalling thread. Will this cause any multi-threading issues with the key provider potentially being used at the same time as frame crypting?
There was a problem hiding this comment.
I'm not sure. The signaling thread in FrameCryptor is actually only used to deliver the onFrameCryptionStateChanged event. Internally, a separate thread ["FrameCryptorTransformer"] is used to encryptFrame/decryptFrame. Unless we use same thread as a worker thread for DataPacketCryptor to avoid keyProvider contention.
There was a problem hiding this comment.
I don't think they compete strongly by default. It only happens once when retrieving the key_handler key_handler->GetKeySet(key_index); and once when the key ratchet needs to update the key material.
This is essentially similar to the two thread competition in frameCryptor for rtp_sender and rtp_receiver.
TODO: - [x] Core Implementation - [x] Android JNI Wrapper - [x] Objective-C Wrapper --------- Co-authored-by: davidliu <davidliu@deviange.net>
TODO: - [x] Core Implementation - [x] Android JNI Wrapper - [x] Objective-C Wrapper --------- Co-authored-by: davidliu <davidliu@deviange.net>
TODO: