On Tue, Aug 23, 2011 at 07:24:42AM -0700, grndvl1 wrote: > Yeah what I am transferring is raw data from a bluetooth custom > device. We collect the data on the phone then transfer that to a > remote server. Is there a way in FTP to continue where you left off > if the transfer gets interrupted?
Sometimes. It depends on the ftp client and server implementation. Some support it, some don't. If you can ALWAYS be certain that both ends WILL support resuming a broken transmission, use that method. If not, read on for another method (basically a very simple packet---or in this case, chunk---based data communications protocol). Here's another idea for you: have your app split the data into ordered/numbered chunks and transfer them as individual files. Have an application on the server that reassembles those chunks in the correct order. You could then run more than one file transfer channel, and thus better utilize the available bandwidth (up to a point, after which you start losing efficiency again). When all chunks are received at the other end, put them in order and reassemble them. It's basically a packet-based protocol, but you're relying on the lower-level protocols for error control (unless you want to add that to your chunks, too, which would be a bit more work for the client/server apps, but would be far more reliable). Btw, I haven't looked to see if any Android apps or the SDK supports RAR or ZIP encoding, but RAR supports reducing data to chunks, and I believe ZIP does, as well. If you're patient, and don't mind bogging your remote (collection) device down, you could use one of those to create the chunks, with error correction, sequencing, etc., already built in. But be advised, with such large data files, again, it's probably going to bog down while splitting the data, and it will (temporarily) double the space usage while the chunks are on disk. As packets are received at the server, it checks the check sequence for each. For those that pass, send an ACK for each chunk (by ID). For those that fail, send a NAK. The client then re-sends the chunks for which it receives a NAK. Simple, fun, and effective. In the above scenario, if the link is lost, the client re-sends the chunks for which it did not receive an ACK from the server. If the link is lost again, same story.... Again, this is assuming that you can't be certain that both the ftp client and server are capable of resuming a broken transfer---that would, obviously, be the best option. Anyways, this should give you some things to think about. Have fun. Later, --jim -- 73 DE N5IAL (/4) MiSTie #49997 < Running FreeBSD 7.0 > [email protected] ICBM/Hurr.: 30.44406N 86.59909W Seen in alt.sysadmin.recovery: "Priceless; that's better than telling him to use the Read Manual command with the Real Fast option." Android Apps Listing at http://www.jstrack.org/barcodes.html -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
