Debounce stream management ack requests

[singpolyma]

So that they don't send after every stanza goes out but only when idle.

[sonnyp]

Yeah I messed it up with queueMicroTask sorry.

I'm ok with reintroducing this but I have a couple of questions

1. Why 100ms ?
2. What is the exact use case for this?
3. Could it be covered by "hooking" to sendMany instead ?

Please add a test or we run into the risk of it breaking again

[singpolyma]

1. Why 100ms ?

It's honestly just my go-to subsecond value

2. What is the exact use case for this?

Avoiding sending r too often and keeping the network extra busy. Without debounce I often see r being sent before we even heard from the last one especially during login as a bunch of different iqs go out in a row.

3. Could it be covered by "hooking" to `sendMany` instead

I dont think this is related to sendMany, an application may have mani different parts all sending stanzas out quickly at once that can't or aren't done with sendMany, especially iqs.

…

-- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

[sonnyp]

It's honestly just my go-to subsecond value

It seems a bit low for this use case. Maybe 250ms? Any idea what others do?

My intention with queueMicroTask was to send <r> after each "tick"

So this would send a single <r:

xmpp.send(<foo/>)
xmpp.send(<foo/>)

but not

await xmpp.send(<foo/>)
await xmpp.send(<foo/>)

wdyt of this approach?

I often see r being sent before we even heard from the last one

This could also happen with a 100ms debounce. Should we cancel the timeout and reschedule when receiving a <a/>?

I dont think this is related to sendMany, an application may have mani
different parts all sending stanzas out quickly at once that can't or aren't
done with sendMany, especially iqs.

👍

[singpolyma]

> It's honestly just my go-to subsecond value It seems a bit low for this use case. Maybe 250ms? Any idea what others do?

For sure, 250 could be a fine default.

My intention with queueMicroTask was to send `<r>` after each "tick" So this would send a single `<r`: ``` xmpp.send(<foo/>) xmpp.send(<foo/>) ``` but not ``` await xmpp.send(<foo/>) await xmpp.send(<foo/>) ```

This is exactly what causes the stampede of overlapping ack requests during any flurry of sends eg during first login.

[singpolyma]

Please add a test or we run into the risk of it breaking again

How would you suggest to test something timing-dependent like this?

[singpolyma]

Ok, figured out timer mocks and added a test