not reachable after some stand-by time

Mobile client, f-droid without GCM push, dhtproxy and permanent notification enabled.

Receiving calls seems to work first, but after some hours it stops working.

A guess: Is the dhtproxy properly sending keep-alives to the clients every 14 Minutes? (To avoid NAT Gateway timeouts. Most mobile devices access the Internet through a device operated by the mobile service provider called a NAT (Network Address Translation) gateway. These will typically time out an idle connection after 15 minutes. https://www.isode.com/whitepapers/imap-idle.html)

Related to https://github.com/Corvusoft/restbed/issues/324 and the PR is her https://github.com/Corvusoft/restbed/pull/349

Normally it's ok. But yeah, it's a lead.

changed the description

Thanks, missing keep-alives would explain it for sure.

The 14 minute intervals are for TCP, UDP would require even shorter intervals. I'm not sure, but think I remember these NAT timeouts to be 2-5 minutes?

changed the description

the proxy use TCP :)

Perfect.

Hm, is the patch applied to the jami binaries, or are you waiting for it to come through upstream?

Or, applied to dhtproxy.j.n

In fact, I have just checked. I never finished nor merged upstream my work about TCP keep alive...

So indeed, this could be a major problem.

assigned to @sblin

added 1 deleted label

marked #548 (closed) as a duplicate of this issue

I'm wondering what effect the switch from restbed to restinio will have, for reliability and keep alive.

Edit: The keep alive patch here seems still not applied in upstream restbed.

Will be tested.

For restbed I did a PR here https://github.com/Corvusoft/restbed/pull/349 and https://github.com/savoirfairelinux/opendht/pull/384. But restbed seems dead. So, in fact, we currently choose to wait for @vivanov :)

assigned to @vivanov and unassigned @sblin

changed milestone to %Iteration 9

@ringthing

It will be an enhancement by going away from threads to std::async on top of which restinio is build!

Just tested it with handle-request-timeout and linux time, it works see: 61b4375;

A stupid's question, in you PR I only see something with 60 seconds timeout.

Is that really sending keep-alive packages? For TCP connections, I think these are only required to be send like every 14 minutes, if on a private net IP and there was no other traffic, to maintain the NAT routing tables working and continue to be reachable.

In fact the 60 seconds was historic. At the beginning, the DHT proxy was not really good to support a lot of clients. So having a 60 secs timeout allowed to close the connection as soon as possible (the write operation of the socket fails if closed)

Can be changed to 14 or 13 minutes now.

Thanks everybody, sounds perfect then. :)

(I think the 14 minutes were already reduced for a typical 15 minute timeout.)

changed milestone to %Iteration 10

changed milestone to %Iteration 12

removed milestone

I see devices not being usable because they are becoming unreachable, and don't know what you have planned to do about this issue with its now removed milestone.

Looks like restino has been merged already. But the write_http_response_timelimit(60s) has not been changed to 14 minutes yet (if that is actually a keep-alive timeout). https://github.com/savoirfairelinux/opendht/blob/master/src/dht_proxy_server.cpp

restinio is indeed in opendht, so the next bump should change the behavior but this will need some tests.

with the latest fixes of resubscribe, I consider this issue fixed. as soon as there is a new release, please verify it works for you @ringthing, cheers

closed

mentioned in issue #920 (closed)

reopened

Reopening, as I'm (and many others https://git.jami.net/savoirfairelinux/ring-client-android/-/issues/920) still seeing the same unreliable delivery. Even though dht-proxy is not a new feature anymore.

@terrytw (This was meant for this issue here) The 14 minutes were just a maximum reasonable keep-alive interval I found mentioned. I have no idea what it actually is now.

Now fdroid got unified push

closed

added severityhigh label