this is a general question using Smack 4.1.6, I faced a problem with IncomingFileTransfer if I send a file and the receiver does not accept the request in a certain time. For example, you have a chat app, the receiver receives the message that some file is send to him, but does not accept the request directly. He accept it one hour later, but then, the IncomingFileTransfer to catch the file is aborting and throws NoResponseException. If the receiver instead accepts it directly or after some minutes, everything works fine.
I assume that in the NoResponseException case, the file isn´t available anymore. I was able to store the FileTransferRequest as an object and get it if I want to. This request is still valid after some hours, I can get all the information from that like sender jid, filename etc. So that is not the problem, the problem starts here:
InputStream is = incomingFileTransfer.receiveFile();
After this long time, the InputStream is null. But after only some minutes, it works. I think that there is something happen on the server site, file gets deleted after a while or something in that way.
Has anybody some experience/knowledge about how long the IncomingFileTransfer is able to get the InputStream via receiveFile() ?
I saw this example of FileTransfer:
smack-examples/FiletransferTest.java at master · Flowdalic/smack-examples · GitHub
What is the reason for building two different connections for incoming and outgoing filetransfer? Has this something to do with the problem I faced?
I remember there was some static variable on the OutgoingFileTransfer class, which hold the milliseconds, after which the requester would receive a timeout, if the receiver doesn’t accept it.
This must be RESPONSE_TIMEOUT which is reachable through setResponseTimeout(), thanks for the hint. But the default is set to 60 seconds, but I am able to get the file after some minutes without setting the timeout. But I will give it a try later…
He accept it one hour later, but then, the IncomingFileTransfer to catch the file is aborting and throws NoResponseException.
Short answer: You would want XEP-358 (and/or XEP-137) for the use case you describe (accepting a file transfer after a “long” period of time). For the time being XEP-0363 would also be an solution.
Basic SI and Jingle transfers are designed after the idea that one user which is currently engaged in a conversation with a second user, and one user wants to transfer a file to the other user, and thus the recipient is immediately able to either accept or reject the file transfer.
But XEP-358/137 only solves half of the problem. The sending entity needs to be available at the time the receiving entity tries to request the file. The “HTTP File Upload” XEP (XEP-0363) would be one solution. But it’s bound to HTTP, whereas in XMPP we’d ideally use Jingle and only use HTTP as optional fallback mechanism. I know that some people in the XMPP community want an more XMPPish alternative for XEP-0363 (including me), but I can’t give an ETA when it will arrive.
It worked for me. I first set to 5 minutes, and after seeing that even that was too short, set it to 60 minutes. But as Flow said, the sender must still be online when accepting the file.
yes, both must be online, when accepting (and using the same session / JVM instance). Don’t know how Smack behaves, when the sender got shortly disconnected inbetween the 60 minutes, while the file is not accepted.
I don´t know of the order is important or if it makes a difference if I set the static variable with setResponseTimeout() before or after creating the mOutgoingFileTransfer, but I tested it also with 2 hours and it worked well. Now I am testing how long the timeout could be (6 hours, 1 day, 2 days etc).
I would set both answers, from Flow and CSH to correct, but this is not possible here. At the end, the answer from CSH was the nearest to my approach.
Just for completion, as the method setResponseTimeout() needs an integer parameter, the time is limited to 24 days theoretically, but I don´t know if this is possible on an XMPP connection and I don´t think somebody really needs this. The limit is because an integer has a value range of 2147483647 (±) and a day has 86400000 milliseconds. It´s a simple calculation 2147483647/86400000 = 24,8.
One additional thing: Even if one of the users, sender or receiver, gets offline and it is not downloaded, it´s not possible to get the file if they get reconnected. As soon as the connections is broken, what happens for example if user logs out or if the internet connection changes from wifi to umts (vice versa), it´s not possible anymore. Reconnection also does not work because it´s not the same connection as before.