Messages are delayed in Jami-Android
I have had, at times, messages not going and at other times getting delayed. The latest, ... my messages reached the recipient after 17 hours.
The work around I have used is to: long press app > go to app info > then, clear cache and force close > reopen the app. Sometimes, I reboot my phone.
Just wondering: is this a known issue or is anyone else experiencing similar problems?
Activity
@asasic downloaded SuperFreezZ! Not sure how to use it to only affect JAMI. I think we want to do the opposite of freeze here, or is there a toggle somewhere that needs to be disabled/enabled or is there a perticular setting that I need to set and leave?
At the moment, nothing is working. I and the recipient has given all permissions to JAMI, and done force close and reboots... I have the same account set up on a laptop as well, and, no messages are going/coming. From my phone, messages do go to another account. I am going to look into TOX again!
@asasic I appreciate your help!
Here is what I have:
- DHT PROXY: ENABLED
- DHT PROXY ADDRESS: dhtproxy.jami.net:[80-95]
- DHT PROXY URL list: https://config.jami.net/proxylist
Further,
- UPNP is enabled
- peer discovery is disabled
- stun disabled
- turn enabled
I never touched these settings! However,
I am wondering if I and the recipient should delete what we have and start over (with default settings)? Is is possible that "powers that are" can't eavesdrop so they are blocking jami protocol?
@asasic I am not sure what I did, but it is working better. Staying connected and sending messages. Then, I applied the newest update. And, sent messages with check mark are, now show a circle, i.e. not sent. I toggle ONLINE/OFFLINE and DHT ON/OFF... nothing! It really is annoying. Anyway, I will just leave this here... Thanks for your help!
Same problem here. Not reliable, some messages don't seem to get out (circle icon). Tends to be on one side. Only some? messages seem to eventually get through (long delays).
- Two devices behind same NAT router.
- F-Droid version 202104...
- Apparently default settings (as above)
- Both use to "published port same as internal" or so (5060 grayed out)
Could it be a port conflict? due to using or publishing the same port?
Edited by Ring ThingProblem could also be related to a router quirk, in case Jami is not switching to TCP when UDP only appears to work, but the UDP-NAT is actually flawed (quote from another project https://git.jami.net/savoirfairelinux/ring-client-android/-/issues/505#note_13611):
Wrapping a TCP tunnel around the UDP-based RPC2/SFTP communication protocol between clients and servers. This avoids many problems with firewalls some of which like to treat all UDP as DNS traffic and lose the port forwarding once 'the reply packet' has been passed back. https://github.com/cmusatyalab/coda/issues/55#issuecomment-410312635
Sounds like this could also possibly explain some of the trouble.
Edited by Ring ThingCalling would also fail here (stops after a while without mentioning to be connecting or ringing).
Taking the two accounts offline and back online in the account settings, seems to make it temporarily work again.
So could really seem to be a NAT timeout or flaw, or port conflict, that Jami is not accounting for, yet.
Edited by Ring Thingmentioned in issue #924
mentioned in issue #740 (moved)
@ringthing Thank you for looking into this. I can confirm that this happens: "Calling would also fail here (stops after a while without mentioning to be connecting or ringing)." Also, I have toggled OFFLINE/ONLINE and it has not worked. But, left it for a while (day), and it did work again, on its own.
One thing I like to mention is that my knowledge level is low. This app seems more feature rich underneath than others. Once problems are found, they need to be sorted, of course, but, also, 1) the right options must be set by default (so users don't have to mess with settings) and 2) if users are given options, then, there should be documentation explaining what they are.
I am following along, your work... but it is way above my knowledge level :)
Thanks Chris, good hints, it's the last option in the main preferences.
At least on my side, though, I have Jami installed long ago, had manually enabled the permanent notification, and I do see it, actually two, there is also another one saying "Jami is syncing".
Anybody knows if dht-proxy is properly on by default on all new android installations?
And if the f-droid version has "run in backround" properly enabled by default?
mentioned in issue #839 (closed)
I found a description that seems to point out some measures necessary to prevent loosing wake-up packages even after they actually reached the android device: https://github.com/nextcloud/talk-android/issues/257#issuecomment-812204462
I think the problem here is a very conservative way to keep connection with the DHTproxy.
I read in another issue that the default behavior is a long tcp connection with 14 minutes of timeout. My guess is that after 14 minutes, Jami would reconnect to DHTproxy. However in real world network connections are often times not perfect, and Jami's approach maybe too conservative. (In my country, ISP would terminate long tcp connection in 5 mintues, usually other IM apps would use a heartbeat mechanism, sending packets every 4.5 minutes to keep that connection alive. Other notorious apps would send data every 30 seconds, if not 10 seconds)
I don't know if any heartbeat packets are sent in between, or what mechanism is used to ensure the re-connection works. But from the result it seems to be working poorly.
My suggestion (immature, just my 2 cents):
-
a heartbeat packet should be sent every X minutes to keep connection alive. One of the popular IM in my country with 1 billion users has a strategy called adaptive keep alive, they would use minimal time interval when app is active in the foreground, and within 10 minutes in the background to ensure user experience when user is using the app, then they would gradually increase the interval of heartbeat, until the interval is too long, that connection cannot be kept alive, then they use the longest successful interval minus 10 seconds as their final interval. They would also store the data for that network, so next time you don't have to test it.
-
Force reconnect (sync?) every time network changes (right now every time network changes, only a packet containing info about dhtnode(50 good, 10 incoming, estimated network size, etc) would be sent from DHTproxy)
-
Force reconnect (sync?) every time the app switches from background to foreground.
-
Force reconnect (sync?) every X minutes when long connection cannot be established.
-
Notify users when there is a problem with connection.
Thank all the devs for their hard work, unfortunately under the current status, Jami android is basically unusable for me
Edited by Chris Ocelot-
I look at this issue like this:
If Jami can ensure a smooth user experience with robust connection mechanism, but costs too much battery and/or data, then it's usable but there is room for improvement.
If Jami cannot deliver messages and calls reliably to begin with, there is no point in saving data and battery. This app would be a instantly no-go for most people.
(I have my own TURN server, so establishing direct connection is NOT a problem for me)
Edited by Chris OcelotWhat do you mean by google related services? Whether it is using google apps/framework as opposed to using microg? I ask because I am using microg... the other side I communicate with, is using google services (gapps). Not sure how I would go about, in this case.
When you say disable push notification... how is it specially named in Jami? Turn off STUN, TURN, DHT? At the moment, I toggle account: offline/ online and I toggle DHT: off/on.
You have done some good research and make excellent suggestions.
I however disagree that jami on android is unusable. I have it running on both android and windows and it works well, both with messaging and calling, when it establishes a connection But, I think you are right... connection is lost, otherwise after sometime, which may be a deal breaker for some! The worst thing is if this is a researched/known issue then, at least there can be a temporary fix that users can "push a button and fix" until a more permanent solution is found!
@b16r05 Push notification setting is in another place, Jami's setting UI is all over the place...
When you are in conversation tab, there are 3 dots on top right corner, tap it and there will be a separate menu. The option to always run Jami in background is also there.
As for microg, I have no idea how it works.
What I know is that by default, when you have DHTproxy enabled, DHTproxy will use google's push notification system called GCM to notify you (by sending an empty message through GCM to you) that something is up, and the Jami app would go fetch latest info from DHT network. So obviously if GCM is blocked in your country (like in mine), then it would not work. Disabling the push notification option would make DHTproxy notify you directly, so you can avoid aforementioned problem, however if app is killed in background, then only GCM can reach the app, DHTproxy cannot.
Edited by Chris Ocelotmentioned in issue #552 (closed)
Chris, thanks a lot I think your reports here and in your other issue could also be extremly useful for the devs to iron out the still remaining, but really basic connectivity and setup/ui problems.
Seeing repeated reports about delivery and reliablility problems, I'm sure many many more first-time users continue to simply discard Jami very quickly, unfortunately.
@ringthing Thanks.
I really like Jami, but it is really frustrating when a messaging app cannot deliver message reliably. I have done all I could by setting up my own servers, but it does not seem to work as intended.
@sblin Not sure if you are the right person to contact, I'd still like to recommend to have a look at the fundamental connectivity issues that tend to rule out using Jami, maybe in a joined effort with issue reporters.
Topics
- non-working defaults and exposing configuration options that require conditional configuration, instead of deriving protocol/codec/server details from basic options. https://git.jami.net/savoirfairelinux/ring-project/-/issues/1218#note_27852 https://git.jami.net/savoirfairelinux/ring-client-android/-/issues/924#note_27861
- NAT handling (multi-client address conflicts?, timeouts, UDP reply drops, ...)
- Timeouts and keep-alives, online status
- Android internal wakelocks and races https://github.com/nextcloud/talk-android/issues/257#issuecomment-812204462
Edited by Ring Thing@terrytw Thank you, I got to the "run in background" setting and disabled it. This is a different menu I keep forgetting about.
I do not have anything of google on my phone, as I use microg and f-droid... at most fake-store and fake google stuff.
I think I follow your discussion on DHTproxy/GCM. For now, at least, I have another setting to try in case things are not working.
@ringthing Thank you. I appreciate your efforts in trying to get this issue some attention.
Guys, please try the latest version, I think they have made significant improvement regarding connectivity.
It is still not perfect, but if you can spot problems consistently, I think it will help them further improve it.
You need to sign up for beta test program in the play store, to get 20210504-1 version 297.
@terrytw I tested! Wow! Never seen it this fast in my life... LOL! Messages from my laptop to phone and vice versa are "instant"; not the case earlier! Can't say for connectivity, although it looks good, will need more time! Thanks!
mentioned in issue #1171
