May 28, 2016 at 1:39 PM
Edited May 29, 2016 at 5:12 AM
You think and you are right. I want to eventually replace the Timers with a single Thread in the RtspClient and eventually multiple threads per TransportContext for the RtpClient.
That is more or less an extra performance thing and in that time the buffer will still be shared but the offsets and lengths in the buffer will be dedicated which will ensure no locking is required.
Sockets are Full Duplex which means I can send and receive at the same time especially with Send and Receive buffer sizes @ 0 and no coalescing under TCP.
When the Timers run or a message is sent InUse is checked along with Reset of the ManualResetEvent which only is used to ensure that if Blocking sockets were utilized that the Blocking timeout would happen less and when not that there would be less chance of
a double poll when a single socket was used e.g. in SharesSocket.
Synchronized is just as effective as lock(somethingElse) when your only using it for one thing, e.g. sending Rtp or Rtcp or Rtsp, when used in a static it locks the type.
Finally Rtsp was designed with an errata for the
framing because it is both a valid UTF8 character and listed in the SAFE grammar in the RFC (which is dumb at best because even HTTP doesn't allow it so they thought they were cute and used a character
which appears not only in legit data from Rtsp but which also signals their start of frame)
This means when in some cases you have $ at the offset 0, the RtpClient will receive this data, in something LIKE ffmpeg it's skipped, where as my lib actually allows for it to be chunked to the upper layer to complete the RtspMessage.
Thus the RtpClient may say it has an packet but there will be no TransportContext associated unless the packet was specially crafted in a way that it does, which is also dealt with by my other packet verification functions.
I hope this answers your questions and eliminates your thoughts on memory corruption, further more such corruption would be met with exception by the CLR if indeed was the case.
Worse, they [IETF] move(d) to make 'independent' framing e.g. RFC4571 standard in RTSP 2.0, but they don't say how one you would use both interleaved and independent on the same connection, they don't say how proxies are to handle ssrc or payload overlaps (e.g.
for proxies) without the channel from the framing and finally they don't even provide a decent list of checks or logic to perform when any of this happens, they just say to 'skip' the data. (not even provide it to the upper layer) which is totally wrong and
causes legit messages from RTSP etc to be missed or 'corrupted'
I believe you simply mean that you don't understand how data is passed around in the library.
Futhermore I think you mean that you don't understand how and when to lock.
See the UnitTests which demonstrate this then try the same with another library :)