Does anyone know of a way to improve file transfer reliability. Messaging seems OK but its pot luck if file transfer (and picture transfer) works. The work around I am using is for both sender and receiver to kill and restart Jami. Then one or two transfers will work before “Failed to transfer”
A probably very silly question : you are aware that for the transfer to succeed both of you must be online at the same time?
This being due to the way Jami works, without a central server (so no one can switch Jami off)
This happens to me too, even when we are both online.
I think the problem is with one of the contacts phone. It happens when I try to send a file during a chat. I have tried iphone to iphone and images take much longer (10-15 seconds) than expected to be delivered via imessage - hence why I think it a handset issue.
Not sure about iMessage, but apps like Whatsapp perform (lossy) video and picture compression before sending the file, but Jami sends files as-is.
An original photo with size 4624 x 2604 can easily be 2MB. A 64 MegaPixel photo can be as much as 13MB. That will contribute in the time it takes.
Also, download-speed(received side) is often quite good for both wifi/Lan and 4G,
but uploading(sending side) on a Lan could take some time depending on your internet-connection.
Maybe compare the received file size on imessage with that of Jami, for comparison?
(FWIW: i did a speed test with windows10Jami(cable lan) 71 MB file sent to Adroid10Jami(wifi on lan), 100mbit LAN. First both “DHT-proxy” enabled. and then both “DHT-proxy” disabled. Both scenarios seemed to take the same time; about 1minute and 5 seconds.)
DHT proxy or not, this will not change the transfer as the transfer is done on a p2p link and the DHT is not used at this point
ah, thanks. i confused “DHT proxy” purpose with “TURN server”
Disabling the TURN server will not really change anything. The TURN server is used only if no other link (local/direct/upnp) are negotiated. The only thing it will change is if TURN is mandatory, you will just not connect and the file will just fail cause the link can’t be created
Thanks. am i correct to say
- ‘local’: on the same device,
- ‘direct’: found destination ip on the openDHT and no firewall is obstructing, connection succeeds.
- ‘upnp’: found destination ip on the openDHT but firewall is obstructing, but “upnp is enabled” and firewall accepts upnp settings, and upnp setup succeeds, and connection is able to pass through the firewall
- “TURN being mandatory” mean, “turn is enabled” and all above failed so no other way to communicate?
local = same network. But yes, it’s correct.
another note is that only one side with upnp is enough.
really? how can it be that one side is enough? (i’d think each jami behind firewall needs to fix it himself)
Also, i saw on a router many ports being opened by upnp, can i be sure jami closes them again, or does it re-use a fixed set?
(sorry for all the questions, you seem like a knowledgeable guy, and i want to really get to know the details so i can help troubleshoot in my environment)
For me, client to client text chat is the only reliable feature on Jami, based on two clients can send text messages to eachother reliably, can the text communication procedure be utilised to initialise a file transfer? I’m just getting a little fed-up with seing “Unjoinable peer” ~90% when trying to initiate any file transfer.
You just have to remember that any traffic is reversible. Like if you are a mobile device behind 10 layers of nat, not upnp support whatsoever, but as long as you are connected to the Internet, you can still watch a youtube video, right? How does youtube server connect to you and send the video data to you? The answer is that youtube simply sends data back the way it came: from you. At each point of the nat chain, the gateway will simply send back the data where it came from.
It’s basically the same case for Jami, both devices will be actively trying to connect to each other, the one device behind layers of nat will be able to connect the device which has upnp activated, then data could flow both direction.
As to your second question, it will, I have tried. You can try disabling upnp, disconnect Jami, then swipe (assuming you are using an android phone) Jami from recent tab, open the app again and hit connect, that should clear all the upnp rules. If not, try different orders of the three things: disconnect and reconnect; disabling upnp; swipe away the app.
If both devices are using mobile data, then the only way to connect to each other is through TURN server (as intermedia), in this case, Jami is basically a inferior whatsapp, since this is exactly how whatsapp, telegram, facebook messenger works, except Jami only has one server with limited capacity.
If you want to use Jami the way it intends to, you need what was mentioned above: ‘local’ ‘direct’ or ‘upnp’.
I thought data is sent direct client to client, encrypted, an exception being a helper/resolution server? for presence and client to client details.
“direct client to client” is the original intention, unfortunately in real life there are all kinds of obstructions. If you are using mobile data, you only get a private IP, like 100.*.*.*., which is not accessible from outside. You can understand it like a building with a lot of apartment units, but the gatekeeper would not allow you in, the furthest you will be able to reach is the reception. Your phone is like a resident on 3rd floor, room 3015. But the outside cant reach you. You can reach outside by sending mails, then when they reply to you, the reply will be send back to you. But anyone who is trying to reach you without you initiating the dialog, will just be stopped at the reception. If you and your friends both live in such buildings, (different location ofc) then you will never be able talk to each other, you will be stopped by his gatekeeper, vice versa.
I gathered there are issues with rotating IPs - especially woith mobile devices, my phone migrates from Wifi to GSM to Wifi many times a day and I guess that may also apply to cell to cell whilst out and about. I found better luck with the desktop client.
As messaging works fine, client resolution cannot be an issue, eg, Fred sends Jack mail though the postal system across town OK, why is Fred having trouble sending a parcel (file) to Jack when mail is still getting though?
Simplistic I know but has Jami tried to take on the impossible?
Rotating IP is not the problem - inaccessible IP is.
Fred sends Jack mail directly - failed.
Then the mail was delivered though the postal system - success, that is because there is the post office as intermedia
Then Fred send Jack parcel - post office out of capacity, fail.
If you failed to establish direct connection, then your only option is to go through the post office, AKA the TURN server, which is very limited in terms of resources.
You can setup your own TURN server to deal with this problem(setup your own post office with huge capacity only serving Fred and Jack).
Regarding TURN server, do you know of a good Docker image to use?