jdev - 2019-09-03

What do you do if a join presence to a MUC times out? If you are just on a slow network, eventually the join will complete. If the remote MUC server is down, you don't quite know.

Swift says something like "No response has been received yet, maybe you're never going to join".

(Not those exact words)

(using a library with a "hard" timeout isn't exactly helping, btw)

There's almost no instance in XMPP where a hard timeout is helpful at the protocol level.

I wondered why my message parser was crashing on a null pointer dereference, but it was because the join didn't complete in 30s before that, and thus the controller object was decomissioned.

Kev: establishing a c2s connection from a mobile client.

I said 'at the protocol level' deliberately, because session startup is an exception.

I tend to agree. It would be great to have a mechanism that triggers a soft-timeout handler without actually removing the success handler

so that you can show "this is taking unusually long. please be patient"

(this is also not how most APIs work)

In Swift we just go a layer above.

So the layer that asked for the MUC join displays the message if the library hasn't announced a completion yet.

Hm, yeah.

how can a join timeout wihout response?

should your own server not tell you that the muc server is not reachable

lovetox: it can't. But there are libraries that expect the join to be finished in a given pre-defined time

Theoretically, it can't.

ok but 30 s seems a long time

I was thinking 30 seconds was no time at all :D

i would say servers should respond faster with a timeout error

In practice, there is no s2s 0198, so your presence might well get lost while the remote server is tearing down

lovetox: a) mobile connections tend to be veeeeery slow.

I experience minute long delays on my usual train to work.

Mobile connections are fast compared to some things.

yeah ok, Gajim never timesout, it just says endless "joining..."

b) setting up s2s is friggin' complicated, with dialback and unhappy eyeballs etc.

sometimes you only have a unidirectional s2s, so your join completes fast, but you never get the responses back.

distributed systems are hard. let's go shopping!

fwiw (somewhat related to this discussion) i always iq before join

i need that to decide what to put into the history tag anyway

and then i know if i get a server not found or something

Daniel: what do you do if the IQ isn't responded to?

display joining… i guess

but it seems less likely than a lost presence

forever?

That'd massively delay joining the MUC if there's a slow link though, wouldn't it?

presumably

Kev: there is no other way to know whether that JID is actually a MUC

Unidirectional s2s is problematic, that would eat your iq-reply too.

can't we just have s2s-0198?

But with an IQ my server should send me a timeout back no? If it gets no answer. Or will it just wait that the kernel kills the tcp socket if the connection is borked?

Prosody won't

pep.: your server doesn't track IQs to remote servers

pep.: so if there is a unidirectional s2s connection, you'll wait forever ✏

Great

Well slix will timeout at least.

And 198 doesn't actually help with that

Zash: why not?

198 is also unidirectional

It has nothing to do with replies

I mean, it will not detect/fix unidirectional s2s, but it will restore all messages after a successful reconnection

Will it?

You only need to kick it hard enough?

Reconnection support isn't mandatory afaik

A _sane_ implementation of 0198 will help

Does that exist?

xmpp:chat@xmpp.rs?join < xmpp-rs is moving there

Anyone aware of any XMPP software that requires an XML declaration at the start of each stream?