ftp client, data connection question (stupid question #2)

[MadHatter]

ok, I know this isnt an ftp users group, but since you're familiar with ftp I figured you might be able to help.

as I said in my previous stupid question, I'm new to the protocol, and am trying to get a grasp of things.

I wrote a .net client & tested it against fzs, and everything works great, but now when I test it on other servers, I'm comming across some problems w/ how my data connection is implemented and wondered if you had any pointers for me.

when you upload a file, closing the socket is an implicit EOF, but now I'm testing on another server and when I open a data connection for an nlst, it sends me the first directory (the socket shows that transmission is done), then waits a few moments then sends me the rest. because of this, my library is attempting to recieve the 226 response before its actually done sending the file list. is there any indicator on the data connection that the list is complete, because It seems I cant rely on .net's stack read functionality to signal completion of a read list.

rfc 959's brevity on the command doesnt leave me much to go on...

[botg]

The server has to close the connection after sending all data and send a 2xx reply code. Due to the nature of the internet, close notification and reply can arrive in switched order.
Assume the transfer got finished properly if you get both a socket close notification as well as a successful reply code in any order.

I don't know how .net handles sockets though, better read the documentation and ask in a .net newsgoup or forum to get more information.

[MadHatter]

ok thanks!

I guess I just wait until the server closes the dc.

[danopia]

The way .NET handles sockets is that you poll the socket - just poll for reads first, then poll for closings. Normally, even if the socket is closed, the .NET socket will stay 'open for reading' yet 'closed' according to it's state property until the data stream is either cut or over, then the poll returns 'offline' and it's your responsibility to shutdown/destroy the socket.

I know a lot about .NET Sockets, mainly because I wrote an instant messaging server/client with it, and a bunch of other stuff (you should see my web server).