"Adrien Reboisson" <adrien-reboisson-at-astase-dot-com@lala.com> wrote in
message news:473c9fc2@newsgroups.borland.com...
> Are writing functions also concerned by this behavior ?
When you write data to a socket, the data is merely copied to the socket's
internal buffer. It is not transmitted right away. When the buffer fills
up, or at least reaches a certain threshold decided by the socket, then the
socket enters a blocking state (since Indy uses blocking sockets) until the
buffer is transmitted and flushed.
When the socket is disconnected abnormally, it does not know that is is not
connected anymore, and thus will happily continue accepting new data without
error until it enters that blocking state, at which time it becomes subject
to the same type of internal timeout that I described earlier.
> why is there no TIdIOHandler.WriteTimeout property ?
Because there is no way to implement it in a reliable cross-platform manner.
Unlike reading, which has a defined standard in the socket API layer. Well,
the same API can be used to query if a socket is ready to accept new data,
but there is no way to determine how much data it can actually accept.
Gambit
