TCP stream - Eof() - help!

I'm experimenting with an automatic FTP upload program to do patches for my game and I'm having trouble with the TCP stream.

I thought Eof() returned True if a TCP connection had been closed. However it's returning True when a connection is still active. (I think it happens whenever I read to the end of the incoming data from the FTP server).

So can somebody say for definite:

1. How I can tell when the server has finished sending lines to me and is ready for another FTP directive.

2. How I can tell if the TCP connection has been broken.

Thanks.

I think you need to work with a timeout for a "broken" connection, since tcp isn't a true stream anyway, instead it's a packet system.

Maybe you can solve the problem with reading incoming data as Lines. And you might ask for the file size before downloading it.

Jfk,

I am reading data with ReadLine(). Blitz's TCP already times out if the connection breaks, and supposedly gives a -1 result for Eof().

Anyway, I'm not downloading any files, that uses a whole seperate stream with FTP. I'm just reading in the nonsense data (message of the day and all that, about 20 lines worth) that the server sends me, before being ready to receive commands.

I think there's either a bug in Blitz (Eof() returning True when it shouldn't), or the documentation is wrong.

Well, I had a little webcam server on tcp base that used to work on WinME, but not on Win98 - using the same firewall settings. It was using the small http server example from the code archives, modified to work with http 1.1. So I wouldn't be surprised if there is some kind of incompatibility. Anyway, FTP Servers tend to speak in many languages, you know, there are so many diffrent protocols and standards that most FTP Clients are not compatible to some Servers (at least not with the default settings).

But, isn't it the way that a FTP server sends two blank lines (chr$(10)) when he said what he wanted to say? OR was that HTTP? Pretty confusing. Maye there is some kind of FTP EOF Signal, at least on some servers...

I reccomend to print out onscreen the server answers to see if there is some kind of convention, and last but not least have a look on the RFC Specifications about FTP: http://www.rfc-editor.org/rfcxx00.html

if not readavail(tcpstream) ... then the server has finished to send packages .. this is not the end of a single line, there could be more lines in one package

if eof(tcpstream) ... the server has closed the connection

example:
while readavail(tcpstream)
line$ = line$ + readline(tcpstream)
if eof(tcpstream) return line$
wend

Jfk, FTP uses Telnet. You can actually use a Telnet client to do FTP, except you can't open data connections. The FTP server sends CRLF at the end of each line, and a "220" code means "expecting input", but you don't always get a 220 code, and you don't know how many lines to expect.

Klass, I use ReadAvail(), but it only tells you how much data has actually arrived, not how much has been sent from the server. So I don't know whether to wait for more data to arrive, or start sending.

Just a hint ... why not use the WinInet.dll .. there is a ftp function in it. Its easy to use and reliable.