TSBPD disabled, TLPKTDROP enabled, Receive Buffer will be full

[kubbo]

Hi, I want disable TSBPD and use my latency control, So I disable TSBPD and enable TLPKTDROP.
Run for a while in a weak network, I found the receive buffer is full , the log display "No room to store incoming packet seqno xx" .

So I read the source code , found when TSBPD disabled, The receive buffer "m_iStartPos" only updated in releaseNextFillerEntries,

So when TSBPD disabled, How to solve the receive buffer full problem ?

[ethouris]

TLPKTDROP isn't working if you don't have TSBPD on.

If you use simply a plain message mode, you can set up a timeout for a message to be delivered, and after it passes, it will be no longer recovered. This is decided on the sender side and works more-less like that if the message expires, it expires on the sender side and if the receiver still tries to recover lost packets that have been already abandoned on the sender side, the sender side should send UMSG_DROPREQ in order to inform the receiver that it is not able to recover this message.

Now, this part you highlighted refers to out-of-order reading of the messages, that is, delivered is the first message that is reassembled from incoming packets, provided that it was sent with clear order flag. This means that the message is extracted from the buffer, so it won't be read next time, but the position of the buffer is unchanged because there are still earlier unfinished messages potentially to deliver. When the receiver party receives the UMSG_DROPREQ message, it deletes the packets in the receiver buffer up to the given sequence number, no matter if some of them have arrived already or got lost. And this means the initial part of the buffer (up to this sequence) is freed.

That second part you highlighted is checking if after extracting a message (could be this time some packets from the beginning of the buffer as it has been finally reassembled) there are any packets of the next messages following, which have been already extracted earlier per out-of-order reading. This function simply finds such a situation and frees also the part of the buffer so far occupied by the already extracted message.

You should find appropriate parameters in the API for srt_sendmsg and the structure SRT_MSGCTRL passed to srt_sendmsg2 function.

[maxsharabayko]

TSBPD OFF and TLPKTDROP ON is indeed not valid use case at the moment.
The main reason behind is the timestamping rule: if TSBPD is disabled, all data packets are timestamped with the sending time, not the origin time they were submitted to SRT for sending. Thus in such configuration TLPKTDROP does not actually have a proper timing information to drop too-late packets.