-
Ge0rG
Kev: did you have some time to ponder about further MUC self-ping options?
-
Kev
It completely dropped out of context, sorry.
-
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)
-
Tobias
dwd, ping
-
Tobias
care to join council?
-
nyco
Board weekly in 10 min ?
-
Ge0rG
hopefully so
-
MattJ
In 5
-
Zash
5 minutes passed in 6m45s?
-
MattJ
My server (where poezio runs) has a perpetually drifting clock, so it's only 16:52 right now
-
jonasw
sudo timedatectl set-ntp on
-
Ge0rG
In 5!
-
nyco
go?
-
nyco
I'll leave at :30 as usual
-
nyco
Mattj, arc, Ralphm?
-
MattJ
Here
-
nyco
2
-
dwd
Martin is unavailable, I'm afraid.
-
nyco
still 2 at :05
-
nyco
dwd, in case wanna catch the air, and put it on paper?
-
dwd
nyco, Erm?
-
nyco
minutes taking
-
MattJ
Looks like we'll be skipping this week
-
nyco
yep, thx anyway
-
dwd
Yes, I'd absolutely love to take minutes, then.
-
Ge0rG
I think we had some other unique client identifier besides resourcepart and 0198 resume-id, but I don't remember any more.
-
dwd
Ge0rG, Muttered about in bind2, no?
-
Ge0rG
dwd: was it separate from the resourcepart proposal?
-
Ge0rG
I really hate the "<client-unique-id>/<server-generated-id>" idea, but I seem to be a minority here.
-
Zash
Eh
-
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).
-
Kev
But if you can come up with something better, I'm sure everyone will be happy.
-
Zash
Maybe satisfying everyone isn't possible.
-
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
-
Ge0rG
Kev: I still fail to follow the "servers need to be able to generate (part of) the resource themselves" argument, unfortunately.
-
Ge0rG
jonasw: they won't try to connect at the same time, hopefully.
-
Ge0rG
jonasw: otherwise, the most recent attempt should win.
-
moparisthebest
why not just let them both log in?
-
moparisthebest
presumably the bad one will time out or disconnect eventually
-
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).
-
Ge0rG
moparisthebest: or consume messages that go into offline storage otherwise... :P
-
Ge0rG
Kev: does it really require a global lock?
-
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.
-
SamWhited
s/use case/requirement/
-
moparisthebest
how else could you tell if the same was simultaneously logging in on 2 different servers in the cluster Ge0rG ?
-
Ge0rG
Kev: I mean: it surely makes it easier, yes. But is it a hard requirement?
-
Ge0rG
don't you end up with a central client<->clusternode lookup table anyway?
-
Zash
If the resource always contains the cluster id?
-
Zash
no
-
Zash
cluster node id* even
-
Ge0rG
Zash: and there will be no other reason for a global lock?
-
Ge0rG
SamWhited: server operators are humans as well.
-
Ge0rG
debugging stuff with UUIDs everywhere is... unpleasant.
-
moparisthebest
or you just use grep
-
moparisthebest
or a search/replace
-
Ge0rG
moparisthebest: often you need to trace the interaction of multiple entities with each other.
-
Ge0rG
text files and grep are not well-suited for that.
-
moparisthebest
so replace them all with yourfavoritenameA, yourfavoritenameB
-
moparisthebest
seems dumb to specify a protocol around pretty names in log files
-
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.
-
SamWhited
*identify
-
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?
-
Ge0rG
SamWhited: yes, but having a readable identifier, like yaxim's resourcepart, actually helps.
-
Ge0rG
SamWhited: because tooling.
-
SamWhited
Ge0rG: what tooling?
-
Ge0rG
SamWhited: bad tooling.
-
Zash
Build better tooling?
-
Ge0rG
Zash: you are the developer. I'm only a sysop.
-
SamWhited
I still have no idea what you're talking about, what tooling is bad? Why would making resourceparts random break it?
-
SamWhited
s/random/server defined/
-
moparisthebest
if you are a sysop that can't use grep or sed you shouldn't be a sysop
-
Ge0rG
moparisthebest: you are right. I should step down immediately.
-
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.
-
zinid
You will end up with global lookup table anyway, because other parts of xmpp suck in this regard
-
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.
-
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?
-
Ge0rG
SamWhited: and I don't buy that we have to break it for no other reason than a potential cloud-scale improvement
-
Ge0rG
SamWhited: because the server I'm using doesn't log client identity on stanzas that are sent via s2s, among other reasons
-
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.
-
Ge0rG
so far I get only one of those three.
-
Ge0rG
SamWhited: but most log lines contain the user JID, which happens to contain a resource part.
-
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.
-
Ge0rG
I never claimed this is a strong argument.
-
Ge0rG
But probably stronger than for keeping GC1.0 ;)
-
Ge0rG
zinid: can you elaborate where you also need a cluster-wide lock when a client connects?
-
zinid
Nowhere, global locks suck in practice
-
zinid
In my practice
-
Ge0rG
zinid: what about the global lookup table?
-
zinid
Well, you cannot get rid of it
-
Ge0rG
zinid: that's what you wrote. What is the reason that you need it?
-
zinid
To wrote to bare jid
-
zinid
Route
-
Ge0rG
zinid: can't you just send to all cluster nodes?
-
Ge0rG
send all messages
-
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
-
Ge0rG
zinid: thanks.
-
zinid
Also, ejabberd has lots of global tables, maintaining yet another one is no big deal
-
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?
-
SamWhited
Please let's not change this into bike shedding about the delimiter.
-
Flow
And what Ge0rG said. Having a client provided resourcepart is essential for debugging, grep does not help here
-
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)
-
jonasw
Ge0rG, re connecting at the same time same client-unique-id: what about a non-XEP-0198 reconnect with lingering TCP session?
-
Flow
Please do not try to kill discussion with "please don't do bike shedding"
-
Flow
SamWhited: Because it helps when looking at an XMPP trace
-
Flow
Especially when there are more then two entities involved
-
SamWhited
Flow: Okay, that's a different use case, how does it help?
-
jonasw
SamWhited, that’s not a different use-case
-
jonasw
not really
-
SamWhited
different from the logs one earlier, I mean
-
jonasw
note that we’re not necessarily talking about debugging a c2s connection onyl, but also s2s connections involved.
-
jonasw
not really
-
jonasw
note that the server isn’t necessarily in the position to add information like client ID to s2s stanzas✎ -
jonasw
note that the server isn’t necessarily in the position to add information like client xep-30 identity to s2s stanzas ✏
-
jonasw
because they might not have that, e.g. if the stanza is inbound
-
SamWhited
Right, that's why it's different from normal logs
-
jonasw
that’s the kind of logs (stanzas going over s2s being logged) Ge0rG is talking about, I think
-
SamWhited
ah, okay, sorry, then yes, adding a server generated tag may not be an option.
-
jonasw
especially if only the stanza "header" (stanza type + attributes) is logged
- Ge0rG is out for now. BBL