Sockets & FTP

[Guest]

I wrote a program that uses windows sockets to download files from a ftp server. It works quite well however I have a couple of snags.

First (and most important) snag: While calling the recieve(buffer,bufferSize,SocketFlags.None) I have no idea how to tell when I have recieved all the data back from a response. Nor do I know how to tell how large the incomming file is (short of querying it beforehand for its size... not exactly what I'm looking for.) I initially found some code on the net that used vbCrLf... it searched for that combination in the data retrieved to signal eof. I was using this combination and all seemed well until I logged onto a different server that had a vbCrLf in the welcome message. <doh>. Just calling the function over and over again until it times out isn't desirable either, this causes uneeded lag in my app and also caused some other error to occur later on in my code. Any input would be appreciated

Second (and not quite as important) While downloading from a unix ftp server (or whatever ftp.netscape.com uses, forgive me for listing that server here.... I'm not aware of any ms servers running a unix ftp server I got 'bonus' bytes back in the data. The exe I downloaded would not run so I downloaded with a different FTP app - the exe worked fine. So I did a windiff of the files, 'Files differ only in spaces', any ideas why I'm getting bonus bytes? I'd like an exchange for the original file please :-

Any help on either item is much appreciated
-- Anthony

 

[Jon Skeet [C# MVP]]

I wrote a program that uses windows sockets to download files from a
ftp server. It works quite well however I have a couple of snags.

First (and most important) snag: While calling the
recieve(buffer,bufferSize,SocketFlags.None) I have no idea how to
tell when I have recieved all the data back from a response. Nor do I
know how to tell how large the incomming file is (short of querying
it beforehand for its size... not exactly what I'm looking for.) I
initially found some code on the net that used vbCrLf... it searched
for that combination in the data retrieved to signal eof. I was using
thiscombination and all seemed well until I logged onto a different
server that had a vbCrLf in the welcome message. <doh>. Just calling the
function over and over again until it times out isn't desirable either,
this causes uneeded lag in my app and also caused some other error to
our later on in my code. Any input would be appreciated!

I haven't checked the protocol, but are you sure it doesn't specify the
size before the actual data comes down? Certainly every client I've
used tells me how big the file is before I start downloading it,.

Second (and not quite as important) While downloading from a unix ftp
server (or whatever ftp.netscape.com uses, forgive me for listing
that server here.... I'm not aware of any ms servers running a unix
ftp server I got 'bonus' bytes back in the data. The exe I
downloaded would not run so I downloaded with a different FTP app -
the exe worked fine. So I did a windiff of the files, 'Files differ
only in spaces', any ideas why I'm getting bonus bytes? I'd like
anexchange for the original file please

You've probably not set the transfer mode to binary beforehand - that
would certainly cause that kind of problem.

Have you considered using a library such as Indy (www.indyproject.org)
instead of writing your own FTP client?

 

[Guest]

.... Using ftp commands I could find out the size beforehand... That wouldn't help me empty the recieve buffer though. If I don't empty the buffer properly the next call to recieve winds up with extra data it does not need. As well responses to the ftp command RECV differ between ms ftp servers and unix server... Status messages (success / failure) get returned as well

Now why would I want to pay someone for an app that I've almost completed?

 

[Jon Skeet [C# MVP]]

... Using ftp commands I could find out the size beforehand... That
wouldn't help me empty the recieve buffer though. If I don't empty
the buffer properly the next call to recieve winds up with extra data
it does not need. As well responses to the ftp command RECV differ
between ms ftp servers and unix server... Status messages (success /
failure) get returned as well.

You should be reading the status messages, etc, and those should be
clearly distinguishable from the rest of the data.

You should generally know how much data to expect, and only call
receive to get that much data - that way you don't get extra data in
the receive buffer.

Now why would I want to pay someone for an app that I've almost
completed?

Who said anything about paying? Indy is free.

 

[Martin Robins]

The FTP server will close the data connection when the transfer is complete.
As such, simply keep reading the stream until it returns and the buffer is
empty and you will have your data.

As for the difference on the UNIX server, there should not be one if you are
in binary mode (TYPE I); otherwise, line feeds will be expanded to carriage
return/line feed pairs.

Martin.

I wrote a program that uses windows sockets to download files from a ftp

server. It works quite well however I have a couple of snags.

First (and most important) snag: While calling the

recieve(buffer,bufferSize,SocketFlags.None) I have no idea how to tell when
I have recieved all the data back from a response. Nor do I know how to
tell how large the incomming file is (short of querying it beforehand for
its size... not exactly what I'm looking for.) I initially found some code
on the net that used vbCrLf... it searched for that combination in the data
retrieved to signal eof. I was using this combination and all seemed well
until I logged onto a different server that had a vbCrLf in the welcome
message. <doh>. Just calling the function over and over again until it
times out isn't desirable either, this causes uneeded lag in my app and also
caused some other error to occur later on in my code. Any input would be
appreciated!

Second (and not quite as important) While downloading from a unix ftp

server (or whatever ftp.netscape.com uses, forgive me for listing that
server here.... I'm not aware of any ms servers running a unix ftp server
I got 'bonus' bytes back in the data. The exe I downloaded would not
run so I downloaded with a different FTP app - the exe worked fine. So I
did a windiff of the files, 'Files differ only in spaces', any ideas why I'm
getting bonus bytes? I'd like an exchange for the original file please