Android版的电脑FTP上传恢复怪现象 [英] Android to computer FTP resuming upload strange phenomenon
问题描述
恢复文件传输时，我有一个奇怪的现象。
看图片下面你看到了糟糕的一节。
这显然会发生随机的，可能每10个时间结果。
IM发送的图片从我的Android手机Java服务器通过ftp。
它是什么，我忘了这里。结果
我看到连接被杀害由于java.net.SocketTimeoutException：结果
转移正在恢复这样
在简历：287609发送976字节的数据
中的字节是当文件被完全接收总是正确的。
即使下面的图片。
说不上哪里开始，因为它的工作大部分时间调试此。
任何建议或想法将炉排我想我完全错过了一些东西在这里。
该设备发送code（只发送循环）：
诠释计数= 1;
//发送N个文件，循环N次
而（计数＆LT; =最大值）{
串SPATH = batchFiles.get（计数1）; FIS =新的FileInputStream（新文件（SPATH））; INT档案大小= bis.available（）; out.writeInt（档案大小）; //大小 串nextReply = in.readUTF（）;
如果该文件存在//
如果（nextReply.equals（Consts.SERVER_give_me_next））{
算上++;
继续;
}
长resumeLong = 0; //跳过这多少字节
INT VAL = 0;
缓冲区=新的字节[1024]; 如果（nextReply.equals（Consts.SERVER_file_exist））{
resumeLong = in.readLong（）;
} //更新@Justin Breitfeller，谢谢
长的SKiiP®= bis.skip（resumeLong）;
如果（resumeLong！= -1）{
如果（！（resumeLong == SKiiP的））{
Log.d（TAG，ERROR跳跃是不一样的resumeLong）;
SKiiP的= bis.skip（resumeLong）;
如果（！（resumeLong == SKiiP的））{
Log.d（TAG，ERROR ABORTING跳跃是不一样的resumeLong）;
返回;
}
}
} 而（（VAL = bis.read（缓冲液，0，1024））大于0）{
out.write（缓冲液，0，val）的;
档案大小 - = VAL;
如果（档案大小＆LT; 1024）{
VAL =（INT）文件大小;
} } 回复= in.readUTF（）;
如果（reply.equals（Consts.SERVER_file_receieved_ok））{
//检查是否所有文件发送
如果（计数==最大）{
打破;
}
}
算上++; }
接收器code（非常截断）：
//接收N档，循环N次
而（COUNT＆LT; totalNrOfFiles）{ INT二= in.readInt（）; // 文件大小
档案大小=（长）二; 字符串文件路径= Consts.SERVER_DRIVE + Consts.PTPP_FILETRANSFER;
文件路径= filePath.concat（theBatch.getFileName（计数））;
文件路径=新的文件（文件路径）;
布尔简历= FALSE; //如果文件存在。跳过如果做或恢复如果不
如果（path.exists（））{
如果（path.length（）==档案大小）{//是否文件具有相同的尺寸
logger.info（文件大小相同的跳跃文件：+ theBatch.getFileName（计数））;
算上++;
out.writeUTF（Consts.SERVER_give_me_next）;
继续; //文件就OK不要再上传
}其他{
//简历上传
out.writeUTF（Consts.SERVER_file_exist）;
out.writeLong（path.length（））;
恢复= TRUE;
档案大小=档案大小-path.length（）;
logger.info（恢复为：+ path.length（）+
发送+档案大小+多字节）; }
}其他
out.writeUTF（放手）;
字节[]缓冲区=新的字节[1024];
// ***********
//接收来自手机
// *********** INT大小= 1024;
INT VAL = 0; BOS =新的BufferedOutputStream（新的FileOutputStream（道路，恢复））; 如果（档案大小＆LT;大小）{
大小=（INT）文件大小;
} 而（档案大小大于0）{
VAL = in.read（缓冲液，0，大小）;
bos.write（缓冲液，0，val）的;
档案大小 - = VAL;
如果（档案大小＆LT;大小）
大小=（INT）文件大小;
}
bos.flush（）;
bos.close（）;
out.writeUTF（文件接收正常）; 算上++; }
发现错误，问题是从我的一部分坏的逻辑。
不再多说了。
我被派遣，目前正在调整他们的发出之前的照片。
问题是，当恢复失败后转移结果踢中
在调整大小的图片不使用，取而代之的是code使用的原始结果
描绘了具有较大规模的大小。
我现在已经设置一个短暂的缓存持有临时调整大小的图片。
在应用IM决策，我只是忘了在简历中的文件是不一样的原始的复杂的光。
I have a strange phenomenon when resuming a file transfer.
Look at the picture below you see the bad section.
This happens apparently random, maybe every 10:th time.
Im sending the picture from my Android phone to java server over ftp.
What is it that i forgot here.
I see the connection is killed due to java.net.SocketTimeoutException:
The transfer is resuming like this
Resume at : 287609 Sending 976 bytes more
The bytes are always correct when file is completely received. Even for the picture below.
Dunno where to start debug this since its working most of the times.
Any suggestions or ideas would be grate i think i totally missed something here.
The device Sender code (only send loop):
int count = 1;
//Sending N files, looping N times
while(count <= max) {
String sPath = batchFiles.get(count-1);
fis = new FileInputStream(new File(sPath));
int fileSize = bis.available();
out.writeInt(fileSize); // size
String nextReply = in.readUTF();
// if the file exist,
if(nextReply.equals(Consts.SERVER_give_me_next)){
count++;
continue;
}
long resumeLong = 0; // skip this many bytes
int val = 0;
buffer = new byte[1024];
if(nextReply.equals(Consts.SERVER_file_exist)){
resumeLong = in.readLong();
}
//UPDATE FOR @Justin Breitfeller, Thanks
long skiip = bis.skip(resumeLong);
if(resumeLong != -1){
if(!(resumeLong == skiip)){
Log.d(TAG, "ERROR skip is not the same as resumeLong ");
skiip = bis.skip(resumeLong);
if(!(resumeLong == skiip)){
Log.d(TAG, "ERROR ABORTING skip is not the same as resumeLong);
return;
}
}
}
while ((val = bis.read(buffer, 0, 1024)) > 0) {
out.write(buffer, 0, val);
fileSize -= val;
if (fileSize < 1024) {
val = (int) fileSize;
}
}
reply = in.readUTF();
if (reply.equals(Consts.SERVER_file_receieved_ok)) {
// check if all files are sent
if(count == max){
break;
}
}
count++;
}
The receiver code (very truncated):
//receiving N files, looping N times
while(count < totalNrOfFiles){
int ii = in.readInt(); // File size
fileSize = (long)ii;
String filePath = Consts.SERVER_DRIVE + Consts.PTPP_FILETRANSFER;
filePath = filePath.concat(theBatch.getFileName(count));
File path = new File(filePath);
boolean resume = false;
//if the file exist. Skip if done or resume if not
if(path.exists()){
if(path.length() == fileSize){ // Does the file has same size
logger.info("File size same skipping file:" + theBatch.getFileName(count) );
count++;
out.writeUTF(Consts.SERVER_give_me_next);
continue; // file is OK don't upload it again
}else {
// Resume the upload
out.writeUTF(Consts.SERVER_file_exist);
out.writeLong(path.length());
resume = true;
fileSize = fileSize-path.length();
logger.info("Resume at : " + path.length() +
" Sending "+ fileSize +" bytes more");
}
}else
out.writeUTF("lets go");
byte[] buffer = new byte[1024];
// ***********************************
// RECEIVE FROM PHONE
// ***********************************
int size = 1024;
int val = 0;
bos = new BufferedOutputStream(new FileOutputStream(path,resume));
if(fileSize < size){
size = (int) fileSize;
}
while (fileSize >0) {
val = in.read(buffer, 0, size);
bos.write(buffer, 0, val);
fileSize -= val;
if (fileSize < size)
size = (int) fileSize;
}
bos.flush();
bos.close();
out.writeUTF("file received ok");
count++;
}
Found the error and the problem was bad logic from my part. say no more.
I was sending pictures that was being resized just before they where sent.
The problem was when the resume kicked in after a failed transfer
the resized picture was not used, instead the code used the original
pictured that had a larger scale size.
I have now setup a short lived cache that holds the resized temporary pictures.
In the light of the complexity of the app im making I simply forgot that the files during resume was not the same as original.
这篇关于Android版的电脑FTP上传恢复怪现象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
