B4A Library New Net library - Android FTP, SMTP and POP3

Status
Not open for further replies.

biometrics

Active Member
Licensed User
Longtime User
I see it now. The REST command is not sent by default. You will need to send it using SendCommand.

Hi Erel,

I finally had a chance to test this. You are sending a "TYPE I" before sending the "RETR" command. The RFC states there may be no command between the "REST" and the "RETR". By sending the "TYPE I" it's cancelling the "REST". Could you remove the "AsciiFile As Boolean" parameter and make it a separate function. Or could you do a "TYPE I" when you connect and log in as the default and only change it if "AsciiFile" is true. Surely most people transfer as binary anyway, after all ascii files can be transferred as binary.

Without resume we can't complete out project. We use 3G and we often get disconnects and we transfer large media files. The way it is now it will always start from the beginning.

Hoping to hear positive news from you soon.

RFC: RFC 3659 - Extensions to FTP

The server-PI will respond to the REST command with a 350 reply, indicating that the REST parameter has been saved, and that another command, which should be either RETR or STOR, should then follow to complete the restart.

My FTP server log:

B4X:
Wed Mar 28 12:03:47 2012 [pid 3] [1000002] FTP command: Client "41.185.xxx.xxx", "REST 711,200"
Wed Mar 28 12:03:47 2012 [pid 3] [1000002] FTP response: Client "41.185.xxx.xxx", "350 Restart position accepted (0)."
Wed Mar 28 12:03:47 2012 [pid 3] [1000002] FTP command: Client "41.185.xxx.xxx", "TYPE I"
Wed Mar 28 12:03:47 2012 [pid 3] [1000002] FTP response: Client "41.185.xxx.xxx", "200 Switching to Binary mode."
Wed Mar 28 12:03:47 2012 [pid 3] [1000002] FTP command: Client "41.185.xxx.xxx", "PORT 41,185,xxx,xxx,148,125"
Wed Mar 28 12:03:47 2012 [pid 3] [1000002] FTP response: Client "41.185.xxx.xxx", "200 PORT command successful. Consider using PASV."
Wed Mar 28 12:03:47 2012 [pid 3] [1000002] FTP command: Client "41.185.xxx.xxx", "RETR /1000004.swf"
Wed Mar 28 12:03:47 2012 [pid 3] [1000002] FTP response: Client "41.185.xxx.xxx", "150 Opening BINARY mode data connection for /1000004.swf (6807317 bytes)."
 
Last edited:

biometrics

Active Member
Licensed User
Longtime User
Thanks Erel !

I'll test it tomorrow.

Is this a special version or will it become the the standard in your next version?
 

biometrics

Active Member
Licensed User
Longtime User
Hi Erel,

I tested it now ...

You seem to be converting carriage return + line feeds to only line feeds.

E.g. (in hex) 0D 0A has changed to 0A.

I checked the server log, the complete file was served but the resulting file on the device was smaller and I can see in a hex editor that the 0D 0A -> 0A replacement took place.

I haven't tried the resume yet because of this but I do note in the log that you're not sending the "TYPE I" anymore.

I haven't changed my code, I only replaced the Net.jar library.

------------------------------------------------------------------------

Every FTP client, server or developer component I've used supports resume, it's pretty standard. I don't mind activating it in our code.

I'm a little bit worried that if you make me a special version that I won't be able to use updates in the future.

I appreciate that you can't change the function parameters or behaviour as other developers are already using it but perhaps it would be better if you could add another function identical to DownloadFile but that does not have the AsciiFile parameter (I can set it via SendCommand if need be) and does not issue "TYPE I".

------------------------------------------------------------------------

Thanks for your support, I appreciate the quick response.

Looking forward to your reply.
 

biometrics

Active Member
Licensed User
Longtime User
You are probably transferring in ASCII mode. You should use binary mode instead.

Hi Erel,

I have not changed my code at all. This is the function call:

B4X:
libFTP.DownloadFile(sFtpDirectory & sFileName, False, sPath & "/Download/", sFileName)

And the FTP server is in binary mode, from the FTP server log file:

B4X:
Thu Mar 29 11:28:13 2012 [pid 3] [1000002] FTP command: Client "41.185.xxx.xxx", "RETR /smil_1000013.xml"
Thu Mar 29 11:28:13 2012 [pid 3] [1000002] FTP response: Client "41.185.xxx.xxx", "150 Opening BINARY mode data connection for /smil_1000013.xml (1439 bytes)."
Thu Mar 29 11:28:13 2012 [pid 3] [1000002] OK DOWNLOAD: Client "41.185.xxx.xxx", "/smil_1000013.xml", 1439 bytes, 17.58Kbyte/sec
Thu Mar 29 11:28:13 2012 [pid 3] [1000002] FTP response: Client "41.185.xxx.xxx", "226 Transfer complete."
 

biometrics

Active Member
Licensed User
Longtime User
But you asked me to change
The type is no longer set by the library. You should explicitly set it.

Hi Erel,

What I mean is it's the same code as yesterday that downloaded the file correctly but wouldn't resume.

All I did is replace the library, now the files are not downloaded correctly.

I did try to do a "TYPE I" before the "REST" and "RETR". As you can see from the log file the server is sending in binary mode:

"150 Opening BINARY mode data connection for /smil_1000013.xml (1439 bytes)."

The file on the device was 1419 bytes.
 

biometrics

Active Member
Licensed User
Longtime User
I see it now.
There is no way to change this behavior from outside the library.

If you like (and think that it will work) I can make another copy which defaults to binary transfers.

Yes please.
 

biometrics

Active Member
Licensed User
Longtime User
Sunday arrived early...

This version doesn't set the file type and defaults to binary transfers.

Thanks Erel. I only noticed this yesterday as I was waiting for the forum to notify me of new posts, but it didn't this time.

I've tested it now but there is still a command being sent between the REST and RETR thus cancelling the resume point.

Log:
B4X:
Wed Apr  4 11:10:37 2012 [pid 3] [1000002] FTP command: Client "41.185.xxx.xxx", "REST 670,392"
Wed Apr  4 11:10:37 2012 [pid 3] [1000002] FTP response: Client "41.185.xxx.xxx", "350 Restart position accepted (0)."
Wed Apr  4 11:10:37 2012 [pid 3] [1000002] FTP command: Client "41.185.xxx.xxx", "PORT 41,185,124,211,172,106"
Wed Apr  4 11:10:37 2012 [pid 3] [1000002] FTP response: Client "41.185.xxx.xxx", "200 PORT command successful. Consider using PASV."
Wed Apr  4 11:10:37 2012 [pid 3] [1000002] FTP command: Client "41.185.xxx.xxx", "RETR /1000004.swf"
Wed Apr  4 11:10:37 2012 [pid 3] [1000002] FTP response: Client "41.185.xxx.xxx", "150 Opening BINARY mode data connection for /1000004.swf (6807317 bytes)."
 

biometrics

Active Member
Licensed User
Longtime User
I'm afraid that the PORT method is sent from the native FTP library.

Oh no!

As you can see from this it won't work then:


What is the native FTP library you use called? I'd like to read up on it and find out if there is any way around this.

It's pretty much a show stopper for us ...
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…