jdev - 2021-10-23

  1. Sam

    Do any current pubsub implementations support result set management? The spec makes it sound like you can't use RSM from the get-go (it has its own separate way to set max-items and the only example just shows the server returning RSM information and no query using it), but I assume if you can use it on subsequent calls you could use it on the first call and I'm not sure what to do about the conflicting max items (that exist in pubsub and in RSM)?

  2. Holger

    ejabberd's PubSub supports RSM.

  3. Sam

    Thanks; I'll dig in and see what it does

  4. Link Mauve

    sat_pubsub as well.

  5. Sam

    This probably means I should actually get my ejabberd integration tests running again and figure out why it refuses to shut down cleanly

  6. flow

    the question is, do ejabberd and sat_pubsub behave identical in all pubsub+rsm cases?

  7. Ge0rG

    flow: will current versions of smack still fall-back to A/AAAA on the xmpp domain if SRV lookup times out / returns an unreachable host?

  8. flow

    Ge0rG, I think they should, yes

  9. Ge0rG

    Zash has set up client support on https://badxmpp.eu/ and when I try to connect to drop.badxmpp.eu it will end up on the A record and not on the SRV record.

  10. Ge0rG

    roughly 20% of yaxim connections are through yax.im:5222 despite the domain having valid SRV. I'm wondering how much of that is due to smack's incorrect fallback, and how much due to actually broken resolvers

  11. flow

    > when I try to connect to drop.badxmpp.eu it will end up on the A record and not on the SRV record. Isn't that the desired outcome? Or are you saying the information from the SRV record isn't used at all?

  12. Zash

    It seems to me you can't rely on SRV records. This makes me sad.

  13. Ge0rG

    Well, if there is a timeout at resolving SRV, it should re-try resolving. If there is an SRV record, it should be used exclusively

  14. Link Mauve

    A better fallback than 5222 might be WebSocket or BOSH as discovered by XEP-0156?

  15. Zash

    > If the initiating entity receives a response to its SRV query but it is not able to establish an XMPP connection using the data received in the response, it SHOULD NOT attempt the fallback process described in the next section (this helps to prevent a state mismatch between inbound and outbound connections).

  16. Zash

    Note: ≠ MUST NOT

  17. flow

    Ge0rG, "If there is an SRV record, it should be used exclusively " why?

  18. Zash

    Dino for example does the fallback anyways.

  19. flow

    or, what's the harm in the fallback to A/AAAA?

  20. Zash

    Violating my DNS pedanticism!

  21. Zash

    The most heinous crime1

  22. Zash

    The most heinous crime!

  23. Zash

    flow, SHOULD per https://xmpp.org/rfcs/rfc6120.html#tcp-resolution

  24. flow

    in an ideal world, clients would discover all connection transports in parallel, following by trying to connect to all remote endpoints in parallel, and finally using only one

  25. Zash

    Ge0rG, 20%? I believe you said 10% at some point in the past, is it getting worse?

  26. flow

    fun, I actually misread the SHOULD NOT in the RFC as SHOULD (probably because that's what I expected here)

  27. flow

    also not sure what "this helps to prevent a state mismatch between inbound and outbound connections" is about

  28. Zash

    s2s? dunno

  29. flow

    Ge0rG, I should be possible to make the A/AAAA fallback configurable, if that's your desired behavior for yaxim

  30. flow

    ahh the state mismatch thingy probably makes sense in s2s only

  31. Zash

    Doesn't make sense to me, but those words might fit in a s2s context.

  32. flow

    but for c2s I don't see any reason not to try the fallback to A/AAAA, besides the additional time until "could not connect" is returned

  33. Ge0rG

    flow: well, I'm not 100% sure what the "right" behaviour would be, but given what it is now, I can't just turn off the haproxy on yax.im:5222 forwarding to the real xmppd machine

  34. Ge0rG

    Zash: sorry, it's closer to 10% indeed. 273 out of 2561 c2s connections

  35. Zash

    Going for the fallback when you do have SRV records pointing elsewhere, in order to make it work, hides broken resolvers and whatnot, just like happy eyeballs hides broken IPv6. Then it never gets fixed and we can't ever have nice things.

  36. flow

    Ge0rG, irregardless of the right or wrong behavior, it would be interesting to see the exact trace of events that lead to the yax.im:5222 connections

  37. Ge0rG

    flow: yes, but I'm not going to implement analytics in yaxim just out of that curiosity

  38. flow

    not suggesting you should, just suggesting that there is some missing information

  39. Ge0rG

    there always is

  40. Zash

    Mmmmm https://dev.gajim.org/gajim/gajim/-/issues/10658#note_204003

  41. flow


  42. flow

    of all things, but I'd hoped that openwrt did the right thing™

  43. flow

    I tend to believe that client devs need some in-the-field tracing of their clients to understand they various behavior in the wild

  44. Ge0rG

    maybe it's a ten-years old openwrt?

  45. flow

    of course opt-in

  46. Ge0rG

    lovetox: how old is your openwrt?

  47. Ge0rG

    flow: how would it work? submit stack traces of failed connections?

  48. flow

    Ge0rG, stack traces are probably not enough, as certain prior events are also of interest. In general, you want the android log of the app and have the app (and smack) log the right events