Hi Felix,
On 25/03/2021 23:56, Felix Fietkau wrote:
[snip]
> The data structure changes that I pointed out are not a blocker for me.
> I do want to see at least a per-client message limit (in order to not
> regress on accidental DoS).
I posted a v3 with exactly that at around the time you
On 2021-03-25 21:43, Arnout Vandecappelle wrote:
>
>
> On 25/03/2021 10:48, Felix Fietkau wrote:
>>
>> On 2021-03-24 13:27, Arnout Vandecappelle (Essensium/Mind) wrote:
>>> ubusd maintains a per-client tx_queue containing references to message
>>> buffers that have not been sent yet (due to
On 25/03/2021 10:48, Felix Fietkau wrote:
>
> On 2021-03-24 13:27, Arnout Vandecappelle (Essensium/Mind) wrote:
>> ubusd maintains a per-client tx_queue containing references to message
>> buffers that have not been sent yet (due to the socket blocking). This
>> is a fixed-size, 64-element
On 2021-03-24 13:27, Arnout Vandecappelle (Essensium/Mind) wrote:
> ubusd maintains a per-client tx_queue containing references to message
> buffers that have not been sent yet (due to the socket blocking). This
> is a fixed-size, 64-element queue.
>
> When more than 64 elements are queued,
ubusd maintains a per-client tx_queue containing references to message
buffers that have not been sent yet (due to the socket blocking). This
is a fixed-size, 64-element queue.
When more than 64 elements are queued, subsequent elements are simply
dropped. Thus, a client that is waiting for those
