"Robert" <xx@xx.com> wrote in message
news:47a9334d$1@newsgroups.borland.com...
> This then calls the MS Windows send() function and the
> program sits there forevever.
The only way I know of for send() to hang like that is if either:
1) the server is not reading any data, so the socket enters a blocking mode
waiting for its outbound queue to be emptied, which will never happen
2) the network cable got pulled out and the network card doesn't know about
it, or the OS freaked out about it.
> The system (microcontroller) this is being sent to is completely
> hung and requires a power reset.
There you go then. #1 above applies.
> I understand that Indy is *blocking*, but I don't know how to reset this.
send() is frozen because the OS does not know that anything is wrong, as the
controller is not responding to normal traffic. The only way to release a
frozen send() in that condition is to disconnect the socket from another
thread, such as one you create to run an idle timer. Otherwise, you have to
wait for the socket to timeout internally (which can take hours), or wait
for the controller to reset itself, which should cause your client socket to
error immediately if the OS detects the reset.
> This call sequence is in the main program thread.
BAD idea! Move the client code to its own thread.
> IdAntiFreeze is being used.
TIdAntiFreeze can't do anything in this situation. This is a low-level
freeze outside of TIdAntiFreeze's control.
> IdTCPClient.UseNagle = true - I don't know if this matters
No, it does not.
Gambit
