J
>
> Ok, so I can just adjust my Athread.Connecdtion.ReadLn
> TO: AThread.Connection.ReadLn(', 60) ???
Yes.
>
> Why? - I was assuming it could be done by using a TTimer and simply going
> through an array of AThreads and sending a 'ping' to their connection? -
> Maybe a sloppy way of doing it but I thought it should work ;)
It is overkill - you do not need a timer with Indy, or any serial
number, or array stuff. Like Remy says, if the read times out at the
client, send a poll to the server and set a flag to say that the poll
has been sent. If *any data at all* is received from the server, clear
the flag. If the read time out again with the flag set, the server is
not responding.
>> Also, you don't need serial numbers in the pings at all, since the server
>> would only be interested in knowing that data is still flowing through the
>> connection in general, not necessarily what the data actually is.
>
> Very good point!... My thought was to use the serials to basically keep
> track of what pings had received a reply....
Use peer IP address/port?
>
> But supposing soem sort of accidental error has happened (god knows what)...
> if you don't give the client a 2nd chance then it could be wrongly
> disconnected.
Well, if you want, you can keep a retry count at the client, or server,
or both.
EG 56k modem utilising full bandwidth could block a ping - Or
> sending a file down the very same connection would make it unusable for a
> while (until the file has finished). How would I deal with this?
You do not need to - if *any data at all* is received from the other
end, whether this is a poll, poll-reply, command, response, file-chunk,
whatever, clear the flag. If data is being received, the reads will not
time out and the polls will not be sent - they are not needed since data
is obviously flowing. Polls only need to be sent when the data flow
stops, at which point the read calls will start timing out.
Rgds,
Martin
