XSF Discussion - 2017-10-11

  1. Ge0rG

    Kev: did you have some time to ponder about further MUC self-ping options?

  2. Kev

    It completely dropped out of context, sorry.

  3. Ge0rG

    Kev: I'd really like to see at least a short write-up on the other options, because I've pondered some time about what can be done and don't see anything that's significantly different from (1)-(3)

  4. Tobias

    dwd, ping

  5. Tobias

    care to join council?

  6. nyco

    Board weekly in 10 min ?

  7. Ge0rG

    hopefully so

  8. MattJ

    In 5

  9. Zash

    5 minutes passed in 6m45s?

  10. MattJ

    My server (where poezio runs) has a perpetually drifting clock, so it's only 16:52 right now

  11. jonasw

    sudo timedatectl set-ntp on

  12. Ge0rG

    In 5!

  13. nyco


  14. nyco

    I'll leave at :30 as usual

  15. nyco

    Mattj, arc, Ralphm?

  16. MattJ


  17. nyco


  18. dwd

    Martin is unavailable, I'm afraid.

  19. nyco

    still 2 at :05

  20. nyco

    dwd, in case wanna catch the air, and put it on paper?

  21. dwd

    nyco, Erm?

  22. nyco

    minutes taking

  23. MattJ

    Looks like we'll be skipping this week

  24. nyco

    yep, thx anyway

  25. dwd

    Yes, I'd absolutely love to take minutes, then.

  26. Ge0rG

    I think we had some other unique client identifier besides resourcepart and 0198 resume-id, but I don't remember any more.

  27. dwd

    Ge0rG, Muttered about in bind2, no?

  28. Ge0rG

    dwd: was it separate from the resourcepart proposal?

  29. Ge0rG

    I really hate the "<client-unique-id>/<server-generated-id>" idea, but I seem to be a minority here.

  30. Zash


  31. Kev

    Ge0rG: I'm not a fan, but I don't see another solution that satisfies both requirements (that some people want to be able to identify the client by its resource, and that servers need to be able to generate (part of) the resource themselves).

  32. Kev

    But if you can come up with something better, I'm sure everyone will be happy.

  33. Zash

    Maybe satisfying everyone isn't possible.

  34. jonasw

    at least we need to define what happens if two sessions with the same client-unique-id try to connect for the same account

  35. Ge0rG

    Kev: I still fail to follow the "servers need to be able to generate (part of) the resource themselves" argument, unfortunately.

  36. Ge0rG

    jonasw: they won't try to connect at the same time, hopefully.

  37. Ge0rG

    jonasw: otherwise, the most recent attempt should win.

  38. moparisthebest

    why not just let them both log in?

  39. moparisthebest

    presumably the bad one will time out or disconnect eventually

  40. Kev

    Ge0rG: You end up needing to essentially lock the entire cluster otherwise (and it makes routing logic that much harder - it prevents designs like GTalks, which I still think was quite sane).

  41. Ge0rG

    moparisthebest: or consume messages that go into offline storage otherwise... :P

  42. Ge0rG

    Kev: does it really require a global lock?

  43. SamWhited

    "Some people want to identify a client by its resource" isn't actually a use case, so I still think we should ignore it. The resourcepart isn't for humans, if they're trying to force it to be something for humans then they're using the wrong tool.

  44. SamWhited

    s/use case/requirement/

  45. moparisthebest

    how else could you tell if the same was simultaneously logging in on 2 different servers in the cluster Ge0rG ?

  46. Ge0rG

    Kev: I mean: it surely makes it easier, yes. But is it a hard requirement?

  47. Ge0rG

    don't you end up with a central client<->clusternode lookup table anyway?

  48. Zash

    If the resource always contains the cluster id?

  49. Zash


  50. Zash

    cluster node id* even

  51. Ge0rG

    Zash: and there will be no other reason for a global lock?

  52. Ge0rG

    SamWhited: server operators are humans as well.

  53. Ge0rG

    debugging stuff with UUIDs everywhere is... unpleasant.

  54. moparisthebest

    or you just use grep

  55. moparisthebest

    or a search/replace

  56. Ge0rG

    moparisthebest: often you need to trace the interaction of multiple entities with each other.

  57. Ge0rG

    text files and grep are not well-suited for that.

  58. moparisthebest

    so replace them all with yourfavoritenameA, yourfavoritenameB

  59. moparisthebest

    seems dumb to specify a protocol around pretty names in log files

  60. SamWhited

    I don't see what any of this has to do with anything; they can still "trace the interaction of multiple entities with each other" if they use something other than the resourcepart to dientify those entities.

  61. SamWhited


  62. SamWhited

    If you want a pretty name in the log file, use the identity, or assign a pretty name and use it in your log files. Why should that be the resourcepart?

  63. Ge0rG

    SamWhited: yes, but having a readable identifier, like yaxim's resourcepart, actually helps.

  64. Ge0rG

    SamWhited: because tooling.

  65. SamWhited

    Ge0rG: what tooling?

  66. Ge0rG

    SamWhited: bad tooling.

  67. Zash

    Build better tooling?

  68. Ge0rG

    Zash: you are the developer. I'm only a sysop.

  69. SamWhited

    I still have no idea what you're talking about, what tooling is bad? Why would making resourceparts random break it?

  70. SamWhited

    s/random/server defined/

  71. moparisthebest

    if you are a sysop that can't use grep or sed you shouldn't be a sysop

  72. Ge0rG

    moparisthebest: you are right. I should step down immediately.

  73. SamWhited

    I'm all for improving tooling to make things easier than grepping for UUIDs, I just don't understand why a client specified string in a resourcepart (which adds a lot of complexity) is the only possible solution to that.

  74. zinid

    You will end up with global lookup table anyway, because other parts of xmpp suck in this regard

  75. Ge0rG

    SamWhited: it's not the only one. But in a situation where our sysop tooling consists of grep and sed, it is helpful to know the approximate version of clients from things that are actually in the log.

  76. SamWhited

    Ge0rG: Why couldn't you say, add the client identity to log lines, or assign a readable ID to clients when they log in and use that in log lines?

  77. Ge0rG

    SamWhited: and I don't buy that we have to break it for no other reason than a potential cloud-scale improvement

  78. Ge0rG

    SamWhited: because the server I'm using doesn't log client identity on stanzas that are sent via s2s, among other reasons

  79. Ge0rG

    SamWhited: if we follow that line, we'd have to add the client identity, s2s connection identity and module to each log line. I'd love to have that.

  80. Ge0rG

    so far I get only one of those three.

  81. Ge0rG

    SamWhited: but most log lines contain the user JID, which happens to contain a resource part.

  82. SamWhited

    You have to change the server either way (to support new resourceparts or to include more information in its logs), it seems to me that doing the one that doesn't have drawbacks as far as the protocol is concerned makes more sense.

  83. Ge0rG

    I never claimed this is a strong argument.

  84. Ge0rG

    But probably stronger than for keeping GC1.0 ;)

  85. Ge0rG

    zinid: can you elaborate where you also need a cluster-wide lock when a client connects?

  86. zinid

    Nowhere, global locks suck in practice

  87. zinid

    In my practice

  88. Ge0rG

    zinid: what about the global lookup table?

  89. zinid

    Well, you cannot get rid of it

  90. Ge0rG

    zinid: that's what you wrote. What is the reason that you need it?

  91. zinid

    To wrote to bare jid

  92. zinid


  93. Ge0rG

    zinid: can't you just send to all cluster nodes?

  94. Ge0rG

    send all messages

  95. zinid

    Ge0rG: this doesn't scale, I also think you need sometimes to know all connected resources and if you don't have global tab you can only poll all nodes

  96. Ge0rG

    zinid: thanks.

  97. zinid

    Also, ejabberd has lots of global tables, maintaining yet another one is no big deal

  98. Flow

    > I really hate the "<client-unique-id>/<server-generated-id>" idea, but I seem to be a minority here. Do we really have to use '/' as delimiter?

  99. SamWhited

    Please let's not change this into bike shedding about the delimiter.

  100. Flow

    And what Ge0rG said. Having a client provided resourcepart is essential for debugging, grep does not help here

  101. SamWhited

    Flow: I still never got a clear answer, why is it essential for debugging? Why not use something else as an identifier (something that doesn't leak into the protocol)

  102. jonasw

    Ge0rG, re connecting at the same time same client-unique-id: what about a non-XEP-0198 reconnect with lingering TCP session?

  103. Flow

    Please do not try to kill discussion with "please don't do bike shedding"

  104. Flow

    SamWhited: Because it helps when looking at an XMPP trace

  105. Flow

    Especially when there are more then two entities involved

  106. SamWhited

    Flow: Okay, that's a different use case, how does it help?

  107. jonasw

    SamWhited, that’s not a different use-case

  108. jonasw

    not really

  109. SamWhited

    different from the logs one earlier, I mean

  110. jonasw

    note that we’re not necessarily talking about debugging a c2s connection onyl, but also s2s connections involved.

  111. jonasw

    not really

  112. jonasw

    note that the server isn’t necessarily in the position to add information like client ID to s2s stanzas

  113. jonasw

    note that the server isn’t necessarily in the position to add information like client xep-30 identity to s2s stanzas

  114. jonasw

    because they might not have that, e.g. if the stanza is inbound

  115. SamWhited

    Right, that's why it's different from normal logs

  116. jonasw

    that’s the kind of logs (stanzas going over s2s being logged) Ge0rG is talking about, I think

  117. SamWhited

    ah, okay, sorry, then yes, adding a server generated tag may not be an option.

  118. jonasw

    especially if only the stanza "header" (stanza type + attributes) is logged

  119. Ge0rG is out for now. BBL