jdev - 2024-11-01

https://www.notebookcheck.net/WhatsApp-s-new-feature-allows-users-to-organize-chats-with-ease.911968.0.html

to add to the spaces/workspaces/… discussions :)

Wow! XMPP Simply isn't a competitor without having ... is that roster groups?

I read that as being 1:N roster groups. Also, I'm merely bringing that it up to show what's going on elsewhere, no need to put dramatic words in my mouth ;) ✏

Roster groups *are* 1:N?

> Roster groups *are* 1:N? always? Isn't that a UX thing? ↺

Protocol-wise.

> Wow! XMPP Simply isn't a competitor without having ... is that roster groups? Indeed it is. It's funny to me that I just put a UI like this in my last release ↺

WhatsApp feeling the heat from Cheogram :)

> WhatsApp feeling the heat from Cheogram :) 😂 ↺

singpolyma: totally unrelated, is it only for me or does https://blog.jmp.chat/ comes up empty?

rom1dep: try now?

and it's back :)

Hi

With ejabberd max_fsm_queue does anyone know what triggers that to be an issue? It says if client reads slow? But I'm wondering why the server has the stanzas in a queue if they've already been written to the socket? There's a seperate setting for ack queue so it doesn't appear sm related but maybe it is, not sure?

Is your stream ended with policy violation?

I think they implemented this not correct. Gajim had constant policy violations if you joined many much at start

Ejabberd Puts 1000 presence stanzas in a second into the queue and then ends your connection

When we complained the default was raised to 5000 which mostly works now

> Is your stream ended with policy violation? Users are reporting this yes which I'm investigating ↺

So the default used to be 1000?

For ack queue

singpolyma, maybe unrelated but I found the biggest cause of the fsm queue growing excessively was bifrost

As in the queue of stanzas the server sends the client and needs to keep track of until the client has acked them?

There are two queues here

The ack one I didn't ask about, and an fsm one I don't know what it is

Acronyms... What's fsm?

the event state machine

I don't know. That's the question

It's normally the sm ack queue

Simply raise it and everything is fine

mucs will start to deadlock if the queue gets too big

lovetox: right I suspect it is the sm ack queue and I'm trying some workarounds in the client for this. But I don't know what this second fsm queue is

singpolyma: dont

It's a ejabberd problem. Gajim acks on every stanza this does not change a thing

Acks on every stanza even with no r?

Ejabberd will fill the queue always faster he you can read it

my findings where that it never asks for r

maybe it puts sm stanzas into the same queue then the rest

...it never asks for a but still says you have too many unacked? Wut

and not in front

I can send a with no r though. Maybe

But maybe not fast enough you're saying

i came to the conclusion that this is nothing i can solve

some users may have still the old value 1000 in their config

even 5000 can be a problem, i mean there are irc channels with 4000 people, if you join a few mucs of that kind ...

Some have reporting raising it to 15000 to bypass this issue

It is a tricky problem.

How much memory does 15000 stanzas take up?

not much, and the queue will not stay there ..

this is a burst kind of problem

Will be acked in a second or two if done well

But if even two seconds can't be granted me obviously I can't ack in time

if the server does not want to have these big of queues, then it should also stop reading data from other servers

it cannot read continously, and tell the client, read faster or i kill you

Or spool to disk

Or truncate the queue is what I hear prosody does

Our queue is virtually infinite, until you try to do a resumption, which just fails if there's too many items in it.

As you said earlier, the stanzas went in the socket already.

but yeah, this problem is made worse with xmpp design choices of spamming presense on join

singpolyma, what you can do is, join mucs slowly ..

but i always rejected that solution

You know presence is optional in MUC already? :)

I'm happy to say it's an ejabberd bug if there's really nothing I could by by rocking faster etc

Meh the MUC thing is a symptom. Someone can always send stanzas fast for any reason

This is a DoS vector

Large MAM pages can trigger problems like this too.

singpolyma: yeah I think that may have been part of ben's fix now that you mention it (event queue to 15k)

wgreenhouse: Ben's changes are ack queue to 15k and fsm queue to 100k. What I want to know is what effect does that second change even have?

ah interesting.

glad he could connect woth you on that--do you have a pet ejabberd under examination now?

Not yet. I haven't run ejabberd since circa 2007. But if it is unfixable client side as lovetox says then maybe not worth it for me to do that. I'm still just curious what the fsm number means at this point

I don't see this at all after those changes

(the serverside ones I mean)

Right, but those changes may not be practical on a public server. Especially if we don't know what effect they both have

hmm.st is public, just not super large. I guess you could ask ben if he's seen ill effects

it was on a thinkpad for some years

Right, public isn't the main factor size is when we're talking about increased ram usage. But yeah if 15k isn't insane then maybe "just" a higher default. Though it feels like so long as the queue can be filled without exceeding s2s rate limit you've got a DoS vector

yeah. I don't understand how the two interrelate

what are the big public ejabberd-using sites? conversations.im?

That would be the one I would be most curious to know their settings and the impact

singpolyma, there is always a DoS vector or?

you cannot design a server software or hardware that i cannot spam with so much data that it does not function anymore

I mean to dos a particular user in a way the server admin may not notice

by making their incoming queue too long?

this seems so far fetched, it feels stupid to even discuss it

wgreenhouse: yes. would be trivial to do