jdev - 2020-10-25


  1. j

    Hello

  2. Guus

    Is it me you're looking for? 🎶

  3. lovetox

    Ge0rG, whats the value in timing out iq requests?

  4. lovetox

    in a general manner, like every iq request

  5. Zash

    So you don't hold on to the state forever

  6. lovetox

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

  7. lovetox

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

  8. lovetox

    and its bound to happen

  9. lovetox

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

  10. Zash

    To the full JID, ish.

  11. lovetox

    ah yeah

  12. lovetox

    that was it

  13. jonas’

    lovetox, placing limits on things is always good

  14. jonas’

    unbounded memory consumption always bad

  15. Link Mauve

    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.

  16. Link Mauve

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

  17. Zash

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

  18. jonas’

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

  19. jonas’

    to a near-arbitrary address

  20. jonas’

    which can be made to blackhole stuff

  21. Link Mauve

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

  22. Kev

    > 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.

  23. Kev

    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.

  24. jonas’

    yes

  25. Ge0rG

    Kev: there is never the right default value.

  26. Kev

    Quite.

  27. Ge0rG

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

  28. Kev

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

  29. Kev

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

  30. Zash

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

  31. Zash

    ~90 seconds per attempt or somesuch.

  32. Kev

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

  33. Zash

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

  34. Zash

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

  35. lovetox

    memory consumption for a dict wit iq: callback?!

  36. lovetox

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

  37. Zash

    define "billion"

  38. lovetox

    ah a billion is probably too much

  39. lovetox

    but you get the idea

  40. jonas’

    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

  41. Zash

    2Ă—64 bit pointers minimum per dict entry or so?

  42. jonas’

    also hashmap overhead

  43. Zash

    yes, hence "minumum"

  44. Zash

    And 128 bit UUIDs

  45. Zash

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