jdev - 2020-02-09

hm, if i lose internet connection, say disable wlan, my socket does not really care, i can still send endless data on it

i thought that he would throw some error, but nothing

now i read a bit about it and seems this works as intended

so the only way to know if i lost connection is application layer pings

can someone confirm this

?

and there is some other functionality SO_KEEPALIVE, where the system tests if a socket is still connected

but according to the internet the timeout is 2 hours on linux

so not really useable as a client

Yes, this is all correct

There are platform-specific ways to reduce the timeout

damn, brilliant design

Well, the send buffer is finite. And according to tcp(7) (assuming it's about TCP), keep-alive probes would lead to timing out in about 11 minutes on Linux by default, while retransmission attempts would last 13 to 30 minutes. And then there's TCP_USER_TIMEOUT, and I think I've observed it timing out in just a few minutes (not sure why).

yeah i was looking for something in the range of seconds

lovetox, anything in the range of seconds would make things fail on EDGE or GPRS type connections quickly

Or even wifi if you're a bit far from the router

And consume battery/bandwidth

Or ethernet if you just unplug the cable for a few seconds to untangle it :]

in the case of EDGE/GPRS, you can easily get into a fun loop with packets from your closed connection cluttering the bandwidth, making your new connection choke right away.

hm, so what timeout would you suggest?

i think its useful for the client to know if the connection broke down

timeouts are always wrong

problem is if the connection broke down, and client doesnt notice it, stuff stops working

indeed

I suggest to have two timeouts

for sending a message i can just show some icon that indicates the message didnt yet reach the server

one I call the `soft_timeout`, which is the maximum time you spend without receiving any data from the server

(be it whitespace or a stanza)

if the soft timeout elapses, you send a ping

and you wait for at most `round_trip_time` (the second timeout) to receive something (doesn’t have to be a reply to your ping, anything will do)

the good thing about this is that with high-delay links, you’ll still most of the time receive things and thus know that your stream is alive

yeah i implemented this just now

you also save on sending pings when you get stanzas from the server (= saved energy)

but what is the max roundtrip time ✏

is 10 seconds good?

in case of gajim, I’d probably set something like 5 minutes for the soft timeout, and auto-calibrate the round-trip time based on IQ round trips

60 seconds?

something between 60s and 120s is probably ok

5 minutes is way to high, as i said stuff stops working, if user opens his profile it just shows a endless loading screen, if he wants to join a MUC, shows a loading screen, etc etc

lovetox, you can make it more interactive on the application layet

and at this time i want to give the user an indication, hey your connection may be broke down

e.g. if after 15s you have no reply, you could do othre things

such as pinging google or so

but if i have a 5 minute soft timeout, i cant give the user any indication

and if you can’t ping google, suggest that the internte may be down

oh you can

have an even softer 15s timeout on your requests (IQs, MUC joins etc.) which triggers some additional action to make the UX smooth

"This is taking longer than expected. Is your internet working?"

and also listen for OS events about connectivity changes

so 15 seconds :)

if you get a "reconnected to network X" event from the OS, discard your stream and resume using '198

thats the answer i wanted

but 15 seconds isn’t the time after which you should throw away the stream

that’s just when you start talking to your user

that’s also not the time after which you start sending pings

because you just sent a "ping"

(which is your request)

yeah jonas’ i get it :)

uh, although, what could be fun is trying to establish a new stream

i was always talking about the time i wait for the poing

in the background

and if you notice that this works very quickly, but your request is slow, you send a ping to the server. if you don’t get a reply within the time it took to get the new stream past TLS, you know that your stream is borked and you should '198 resume on the new stream and discard the old one

that’s neat actually

establishing a new TCP connection and doing TLS is not that expensive in number of packets and as good as a test as anything else

(it’ll also not clutter your own send buffers further, you can simply discard the new connection (along with its buffers) easily if it doesn’t work out)

jonas’, sorry sounds way to complicated and over-engineered

i wait X seconds, and throw the stream away, much easier

thats what we have stream management for, for fast reconnects

lovetox, that’ll really hurt you

on a bad mobile link

on bad mobile link, stuff will be bad, no suprise for the user :)

but the whole topic is a nightmare, we have many actions on xmpp that need a response

so many action will look to the user like, he clicks something but nothing happens

Show a spinner if it takes more than a few seconds

for some things thats a fine approach

for others its not so nice

deleting a contact from your rosterfor example

dont want to show a dialog with a spinner for that

Show it on the contact then. Like, replace the avatar or status icon or something

you really have to design the whole application for this case

what i think i will be doing, let the user send message when we lost connection

but disable every other action

> lovetox> damn, brilliant design when is a connection "lost"? I don't think there is a better design without loosing some other (desirable) properties

That's what you get when you emulate a circuit over a packet-switched network. All sorts of fun!

lovetox, or just pretend that it has happened for things where you’re rather certain that you can enforce it to happen eventually

for example, contact deletion

queue the operation up and do it when you have connectivity and hide the element from the UI

And then users get confused when they use another client that has connectivity :/

I see the appeal in what you say but I'm not entirely sure I like it

jonas’, sounds easy, but reality is much harder

you can invest thousands of lines of code into this, and it still will be buggy

or you just tell the user, hey right now you cant delete, wait until you have a proper connection to the server

which is totally fine in my book, i dont think anyone expects to do server operations while offline

lovetox: you can change the SO_KEEPALIVE interval on Linux, it's settable if you are root

yay gajim as root :P

Just run it in a container.

yay gajim as root in a container!

a.k.a. flatpak?

or was it snap?

why not both?

Is the process really root? Isn't bubblewrap used just to spawn the thing?

pep., I was making fun of those

probably not root ;)

Well no gajim wouldn't change it, the machine administrator would

With sysctl

Isn't there a per-process/-socket option you can poke if your socket library doesn't hide it from you?

Not for keepalive iirc

Don't worry TCP's replacement is all in userspace not kernel so you can do whatever

:(

But I was excited about TLS in kernel space

I still want to play with that.

I should have a look in rustls.

so if i do the xmpp pings, i guess i dont need the send every X seconds a whitespace

or isthis useful for something else

The whitespace is a keepalive.

yeah though i just learned a socket does not break down, even if i cut the internet, so keeping it alive is not really the issue here

Heh

Some (too many) routers like to silently terminate idle connections

ok but sending a xmpp ping on a idle connection every 15 seconds should keep it alive

Sure

im asking if i need both

15 seconds is kinda frequent :/

You could at least use 198 <r>/<a> for pings, which are lighter

How about 14 minutes

lovetox, that sounds like a battery drainer.

Pidgin does that AFAIK, and it’s terrible.

Don’t be like Pidgin.

hm or i depend on a network manager, to tell me if the internet is down

Aren’t you already doing that with nm?

But jonas’’s approach of using XEP-0198 stream resumption looks quite elegant to me.

That’s what I’d do if I were to start something from scratch again.

what approach is that?

The one from 10:24:16 CET.

Just trying a new TCP connection to the server would at least tell you something about whether it's the existing connection that's broken or all connectivity

or all connectivity to the server*

but thats what a network manager is for

...

It won't detect if someone trips over a cable in the building switch room

Seems like it would require running one though.

or the server suddenly explodes

i think we are mixing 2 things here

detecting if my remote is gone

and detecting if my internet is gone

or is this the same thing?

i hope not

What is your end goal?

either way, network manager tells me when there is no route to the internet, reading the manual

so this includes tripping over my cable

Link Mauve, detecting when i have no connection to the server

lovetox, why do you need to know about the Internet then?

And also, what do you want to do in such a case?

What about if the kernel eventually flushes its buffers and messages you sent now got sent?

i show the user that there is no connection and limit what he can do

That sounds like bad UX when you can instead remember what the user did and then figure out whether it got done or not on stream resumption.

Meh, stupid Freenode sending me tons of presences from IRC…

There was just a notice about them doing some maintenence

poezio is still spending all of my CPU time handling those presences…

so just a simple example

its easy to just store the stanzas that are going out and on failed resumption replay them

but if you think about that the user could close the application while not connected

now you suddenly have to save your not acked stanza cache to harddisk, and on resume you have to judge which of them make sense to send

Yes, it's hard

you have to take into account how much time passed

probably offer UI to ask the user etc etc

a lot of magic that can fail, and end in scenarios where the user just cant understand what and why something happend or didnt happen

compare this with a very simple "You are not connected, so you cant do that right now"

but as it seems, i cant even determine if im connected :D

I agree with lovetox that it's a lot of magic that can go wrong, (buffering and resending when connectivity gets back) :/

for messages only i can imagine it, if i would have proper UI where i notify the user of messages that have not been sent last time, and he can choose to resend

for everything else i would say not worth it

sending messages while being offline would also satisfy a feature request :)

yeah not a problem, but we need UI first that shows that a message has not reached the server, and after X minutes, dont send it anymore instead user has to manually issue a command to resend them

we could use that info bar at the top of each chat control to inform + offer to try again (and mark unsent messages in the chat)

yeah that sentence is a week worth of work :D

sorry, just trying to point out a possible UI^^

I always wanted to use that infobar for more :)