XSF Discussion - 2017-10-11

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

It completely dropped out of context, sorry.

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)

dwd, ping

care to join council?

Board weekly in 10 min ?

hopefully so

In 5

5 minutes passed in 6m45s?

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

sudo timedatectl set-ntp on

In 5!

go?

I'll leave at :30 as usual

Mattj, arc, Ralphm?

Here

2

Martin is unavailable, I'm afraid.

still 2 at :05

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

nyco, Erm?

minutes taking

Looks like we'll be skipping this week

yep, thx anyway

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

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

Ge0rG, Muttered about in bind2, no?

dwd: was it separate from the resourcepart proposal?

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

Eh

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

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

Maybe satisfying everyone isn't possible.

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

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

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

jonasw: otherwise, the most recent attempt should win.

why not just let them both log in?

presumably the bad one will time out or disconnect eventually

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

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

Kev: does it really require a global lock?

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

s/use case/requirement/

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

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

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

If the resource always contains the cluster id?

no

cluster node id* even

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

SamWhited: server operators are humans as well.

debugging stuff with UUIDs everywhere is... unpleasant.

or you just use grep

or a search/replace

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

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

so replace them all with yourfavoritenameA, yourfavoritenameB

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

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.

*identify

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?

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

SamWhited: because tooling.

Ge0rG: what tooling?

SamWhited: bad tooling.

Build better tooling?

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

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

s/random/server defined/

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

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

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.

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

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.

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?

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

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

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.

so far I get only one of those three.

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

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.

I never claimed this is a strong argument.

But probably stronger than for keeping GC1.0 ;)

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

Nowhere, global locks suck in practice

In my practice

zinid: what about the global lookup table?

Well, you cannot get rid of it

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

To wrote to bare jid

Route

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

send all messages

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

zinid: thanks.

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

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

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

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

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)

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

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

SamWhited: Because it helps when looking at an XMPP trace

Especially when there are more then two entities involved

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

SamWhited, that’s not a different use-case

not really

different from the logs one earlier, I mean

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

not really

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

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

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

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

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

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