jdev - 2020-10-25

Hello

Is it me you're looking for? 🎶

Ge0rG, whats the value in timing out iq requests?

in a general manner, like every iq request

So you don't hold on to the state forever

i understand it for specific iqs, where i want to give the user within a timeframe a response

Zash, it cant be forever, because on a non-sm-resume reconnect, all callbacks are invalidated anyway

and its bound to happen

hm that gets me thinking, iq request are not really bound to a session

To the full JID, ish.

ah yeah

that was it

lovetox, placing limits on things is always good

unbounded memory consumption always bad

lovetox, poezio previously didn’t timeout iqs, wishing that every other entity on the network respected this MUST in the spec, and that no stanza would ever be lost over the network.

But with 22k iq handlers in flight due to remote entities not doing that, it made poezio very slow.

Nobody said what time frame the reply must be returned in...

particularly great when there’s a remote way to make poezio send a lot of IQs :)

to a near-arbitrary address

which can be made to blackhole stuff

Now that we have a (IIRC) two minutes timeout, poezio stays fast for much longer.

> lovetox, placing limits on things is always good You say that, but I have seen plenty of issues with different clients putting in arbitrary timeouts because they assume they'll always be used on the same sort of network connection as the author was using.

So, yes, not memory-exhausting yourself is good, but you have to be tremendously careful while doing it if you don't want to break things for someone.

yes

Kev: there is never the right default value.

Quite.

Kev: you might have designed for a 75 bps military satlink, but I'm working on German mobile "broadband".

Although setting iq timeouts to something like 10 minutes is probably safe enough.

I have seen situations in which 5minutesish wouldn't have been.

Due Linux kernel TCP default timeouts, and lack of happy eyeballs, it can take way longer than 2 minutes just to get s2s up.

~90 seconds per attempt or somesuch.

The real best default is "Whatever the maximum length of time is before I can't possibly avoid timing out without failure* locally"

Or you could set a memory budget instead. If whatever state you have takes more than x size, time out the oldest one.

And then like, don't disco#info everyone in those 10000 user MUCs

memory consumption for a dict wit iq: callback?!

not sure on what machines you are, but i could probably store a billion and it would still not really noteable

define "billion"

ah a billion is probably too much

but you get the idea

it soon becomes more than just id: callback; the callback will often have some kind of closure associated to provide more context to the reply

2×64 bit pointers minimum per dict entry or so?

also hashmap overhead

yes, hence "minumum"

And 128 bit UUIDs

... usually encoded as 36 byte strings (+\0 and/or length)