Getting the TCP errorcode from network.dll

[brathbone]

Hi everyone,

I've been working on finally finishing my low-level FTP download with progress code, and I have one final sticking point.

When the FTP file transfer completes, I expect to get an error 102.

In other languages I use the socket.error event.

How can I detect / handle this errorcode using network.client?

Thanks in advance!

 

[brathbone]

Worked around

I solved my problem in a different way. What I did was just check to see if the amount of data received matched the file size.

I would still like to know if it is possible to trap these errors, but it is no longer a pressing need.

Thanks.

 

[TWELVE]

I solved my problem in a different way. What I did was just check to see if the amount of data received matched the file size.

I would still like to know if it is possible to trap these errors, but it is no longer a pressing need.

Hi !

In my opinion, you should read and process the server status codes by your own, since the network lib is not aware of the ftp protocol.I do it the same way for other higher level protocols like smtp or http.

The ftp status code after a successful transfer should be:

226 Transfer complete

If you don't want to send commands "blind" to the server, you to read and process every single answer/status code from the server.The 226 is only one of them.

regards,


TWELVE

 

[brathbone]

Hi TWELVE,

I agree with you about parsing the server status codes. I am actually doing that in the command socket, but the problem is that "226 Transfer Complete" signifies that the server has finished writing the file to its TCP buffer. It is possible that the 226 can come in before the client has received all the data. When I connect to my Mac over wireless, I can consistently reproduce this behavior. When I tried closing the datasocket on a 226, I got partial files.

I believe the true signal that the transfer has completed comes in the form of an error 150 on the datasocket, which I believe is currently being handled silently / ignored by Basic4PPC (I'm really not sure). This is the part I am confused about. In other languages I've used I had a DataAvailable event and an Error event for my socket (client). In Basic4PPC I think I would need the ability to check client.lasterrorcode from within a timer.

Thanks for your response, and any other input is appreciated.

You can have a look at the code in the new open source project I just posted on my website: Low-level FTP Download with progress

 

[TWELVE]

It is possible that the 226 can come in before the client has received all the data. When I connect to my Mac over wireless, I can consistently reproduce this behavior. When I tried closing the datasocket on a 226, I got partial files.

Ok, to be honest, the 226 does not mean in every case, everything went ok, as per the ftp rfc it just mean: Closing data connection.If you sent an ABORT command, the successful exexution would also be acknowledged by the server with 226.Furthermore you also need to know other status codes that occurs before the 226, so it's not enough to just wait for 226.

And of course you need to check, if you received the amount of data bytes you expected.

I believe the true signal that the transfer has completed comes in the form of an error 150 on the datasocket, which I believe is currently being handled silently / ignored by Basic4PPC (I'm really not sure).

I'm not sure, what you mean with a datasocket.As i understand, you talk to the network lib, which is a tcp stack, and i'm not aware of errors like 150 in there.In terms of ftp protocol , 150 means:

150 File status okay; about to open data connection.

This happens right after the RETR command and just before the data transfer of the requested file is starting.

Basic4PPC or the underlying network lib are not aware of the ftp protocol, so
they cannot return ftp status codes.They just return data packets you receive from the server and it is up to you to read and process these.TCP as an underlying layer is also not aware of ftp.It just carries data between a source port and a destination port and ensures, that the data requested is sent & received ( or returning timeout / error).



I recommend to read and follow the RFC:

RFC 959 - File Transfer Protocol


regards,

Frank

 

[brathbone]

Frank et al,

I apologize for the confusion. Most of my socket coding has been done in REALbasic, and I did not realize that the errorcodes I was using were REALbasic specific. I now have a better understanding, which has led me to new questions, but I will address those in their own threads.

Thanks for your input and sorry for the misunderstanding.